Governance/Policies in Advanced Cluster Management for Kubernetes (Part 3)

In this part of my series on ACM, we will cover Governance/Policies.  Another name for this is the Governance, Risk, and Compliance framework.

When we think of governance, security comes to mind.  A big part of ACM policies does have to do with security but it is important to note that the ACM policy engine can push any desired state whether it be security-related or not.  For example, you can use ACM to ensure that all clusters have an LDAP/Active Directory authentication provider defined (even when these clusters are newly created from ACM).  Basically, any object that can be created inside of OCP can be made into an ACM policy.

The official documentation for policies is located at https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.3/html/governance/index#manage-security-policies

After clicking on the "Governance" link (left-side) of the multi-cloud console, the following screen will appear.

Let's create a policy and go through some of the example policies that are included and ones that we can create manually.  A wizard will appear with the raw YAML definition appearing on the right-hand side of the screen.

When looking at the raw YAML, three OCP/CRD objects are defined (referenced by kind).  The policy (policy-grc), PlacementBinding (binding-policy-grc), and PlacementRule (placement-policy-grc).

The policy is the definition of the policy that will be defined.  Since we did not select any specific settings, this is just a skeleton policy.  The PlacementBinding associates the policy with the PlacementRule.  Lastly, the PlacementRule defines a selector that can be used to match a single-cluster (or group of clusters).  The match can either set a policy to be pushed to a group of clusters or be excluded.

Manipulating any of the settings on the left-side of the screen (in the wizard) will automatically update the raw YAML definition that appears on the right-side of the screen.

The policy will need a few settings defined.

Note:  By default, these policies are set to remediation type "Inform" meaning that ACM will not automatically correct any issue.  To make ACM attempt to fix any compliance issues, the remediation will need to be set to "Enforce".

Namespace- The objects associated with the policy need to be stored on the hub cluster in a specific namespace.  Define this namespace here.  The namespace will need to be created ahead of time if it does not already exist.

Specifications- The type of policy to push.  Here are brief explanations of some of these.  Selecting any of the pre-populated policies automatically will populate the standards, categories, and controls fields which are annotations that specify security standards that are met by creating these policies.

 CertificatePolicy- By default, this rule will show any certificates in the default namespace that are within 300 hours of expiration.  The ACM cluster console will show a warning (more on this later).

 ComplianceOperator- This policy will ensure that the Openshift Compliance Operator is installed.  See my separate blog post on this.

For a simple example, let's use the "Namespace - Must have namespace prod".  This example will ensure a namespace called prod gets created on any cluster that matches a PlacementRule.

Populate the following values in the wizard:

On the right-side of the screen (raw YAML), the following modifications are made.

Lines 1 through 33 (shown below) will be explained first

A policy named "policy-namespace" is created in the default namespace (on the hub cluster).  The specific security standard annotations are added (lines 1 through 9).

The spec says that this policy will be "Enforced" meaning that ACM will automatically fix this compliance issue by creating the prod namespace if it doesn't exist on a targeted cluster (line 11).  This setting will take precedence over any spec defined in the ConfigurationPolicy (line 20).

Disabled is set to false meaning that the policy is active (line 12)

The policy-templates contains an object definition for the ConfigurationPolicy

The name "policy-namespace-prod-ns" is defined for the ConfigurationPolicy (line 18).

namespaceSelector is not used in this case (starting at line 22).  It is most often used when we want to include (or exclude) certain namespaces on the destination cluster for checking that an object exists (or doesn't exist) in that namespace.  Since this policy creates a namespace called "prod", there is no sub-object (such as a pod) that we need to check for.  

The object-template (line 27) defines the complianceType as "musthave" meaning that this policy checks for existence of the prod namespace.  The complianceType is not the same as remediation.  The remediation defines the action that will be taken if a cluster is in violation of the policy.  complianceType is just the check for existence.

Starting at line 29 is the objectDefinition.  Notice that the contents of this objectDefinition are regular OCP/Kubernetes objects (IE: namespace).  The only difference is that they are indented and a sub-object of the policy.  

Knowing what we know now (that any OCP/Kubernetes object) can be created inside of a policy, any object or group of objects that can be created inside of OCP can be made into a policy.  A follow-on blog post will follow that shows how to create an oauth/identity provider configuration.  Stay tuned for that.

Now, to the bottom of the raw YAML definition (starting at line 35).

As was mentioned previously, the placementBinding associates the placementRule called "placement-policy-namespace' with the subject/policy that we created called "policy-namespace" (lines 40 through 47).

Line 50 defines the placementRule that uses a clusterSelector (starting at line 58) that has the label "local-cluster: true"

When this policy is created, the local cluster will be targeted and a namespace called prod will be created.

In the video that follows, this policy will be created and I will show policy compliance screens, the impact of deleting the prod namespace/project (it will be recreated because the remediationType is enforce), and deleting the prod namespace/project after setting the remediationType to inform (in this case a violation will be shown but ACM will not correct the issue).