Chapter 4. Integrate third-party policy controllers
Integrate third-party policies to create custom annotations within the policy templates to specify one or more compliance standards, control categories, and controls.
You can also use the third-party party policies from the policy-collection/community.
Learn to integrate the following third-party policies:
4.1. Policy Generator
The Policy Generator is a part of the Red Hat Advanced Cluster Management for Kubernetes application lifecycle subscription GitOps workflow that generates Red Hat Advanced Cluster Management policies using Kustomize. The Policy Generator builds Red Hat Advanced Cluster Management policies from Kubernetes manifest YAML files, which are provided through a PolicyGenerator
manifest YAML file that is used to configure it. The Policy Generator is implemented as a Kustomize generator plug-in. For more information on Kustomize, read the Kustomize documentation.
View the following sections for more information:
4.1.1. Policy Generator capabilities
The Policy Generator and its integration with the Red Hat Advanced Cluster Management application lifecycle subscription GitOps workflow simplifies the distribution of Kubernetes resource objects to managed OpenShift Container Platform clusters, and Kubernetes clusters through Red Hat Advanced Cluster Management policies.
Use the Policy Generator to complete the following actions:
- Convert any Kubernetes manifest files to Red Hat Advanced Cluster Management configuration policies, including manifests that are created from a Kustomize directory.
- Patch the input Kubernetes manifests before they are inserted into a generated Red Hat Advanced Cluster Management policy.
- Generate additional configuration policies so you can report on Gatekeeper policy violations through Red Hat Advanced Cluster Management for Kubernetes.
- Generate policy sets on the hub cluster.
4.1.2. Policy Generator configuration structure
The Policy Generator is a Kustomize generator plug-in that is configured with a manifest of the PolicyGenerator
kind and policy.open-cluster-management.io/v1
API version.
To use the plug-in, start by adding a generators
section in a kustomization.yaml
file. View the following example:
generators: - policy-generator-config.yaml
The policy-generator-config.yaml
file that is referenced in the previous example is a YAML file with the instructions of the policies to generate. A simple PolicyGenerator
configuration file might resemble the following example:
apiVersion: policy.open-cluster-management.io/v1 kind: PolicyGenerator metadata: name: config-data-policies policyDefaults: namespace: policies policySets: [] policies: - name: config-data manifests: - path: configmap.yaml
The configmap.yaml
represents a Kubernetes manifest YAML file to be included in the policy. Alternatively, you can set the path to a Kustomize directory, or a directory with multiple Kubernetes manifest YAML files. View the following example:
apiVersion: v1 kind: ConfigMap metadata: name: my-config namespace: default data: key1: value1 key2: value2
You can also use the object-templates-raw
manifest to automatically generate a ConfigurationPolicy
with the content you add. See the following example:
apiVersion: policy.open-cluster-management.io/v1 kind: PolicyGenerator metadata: name: config-data-policies policyDefaults: namespace: policies policySets: [] policies: - name: config-data manifests: - path: object-templates-raw: | <your_content>
Your content is used in the generated ConfigurationPolicy
and added as an entry for the policy-templates
of a policy. The object-templates-raw
generated ConfigurationPolicy
has the same name as a manifest generated from a ConfigurationPolicy
that has no specified name.
The generated Policy
, along with the generated Placement
and PlacementBinding
might resemble the following example:
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement-config-data namespace: policies spec: predicates: - requiredClusterSelector: labelSelector: matchExpressions: [] --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-config-data namespace: policies placementRef: apiGroup: cluster.open-cluster-management.io kind: Placement name: placement-config-data subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: config-data --- apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: annotations: policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration policy.open-cluster-management.io/standards: NIST SP 800-53 policy.open-cluster-management.io/description: name: config-data namespace: policies spec: disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: config-data spec: object-templates: - complianceType: musthave objectDefinition: apiVersion: v1 data: key1: value1 key2: value2 kind: ConfigMap metadata: name: my-config namespace: default remediationAction: inform severity: low
4.1.3. Policy Generator configuration reference table
Note that all the fields in the policyDefaults
section except for namespace
can be overridden for each policy, and all the fields in the policySetDefaults
section can be overridden for each policy set.
Field | Optional or required | Description |
---|---|---|
| Required |
Set the value to |
| Required |
Set the value to |
| Required | The name for identifying the policy resource. |
| Optional |
If multiple policies use the same placement, this name is used to generate a unique name for the resulting |
| Required |
Any default value listed here is overridden by an entry in the policies array except for |
| Required | The namespace of all the policies. |
| Optional |
Determines the policy controller behavior when comparing the manifest to objects on the cluster. The values that you can use are |
| Optional |
Overrides |
| Optional |
Array of categories to be used in the |
| Optional |
Array of controls to be used in the |
| Optional |
An array of standards to be used in the |
| Optional |
Annotations that the policy includes in the |
| Optional |
Key-value pairs of annotations to set on generated configuration policies. For example, you can disable policy templates by defining the following parameter: |
| Optional |
Copies the labels and annotations for all policies and adds them to a replica policy. Set to |
| Optional |
The severity of the policy violation. The default value is |
| Optional |
Whether the policy is disabled, meaning it is not propagated and no status as a result. The default value is |
| Optional |
The remediation mechanism of your policy. The parameter values are |
| Required for namespaced objects that do not have a namespace specified |
Determines namespaces in the managed cluster that the object is applied to. The |
| Optional |
Use the parameters |
| Optional |
Determines whether objects created or monitored by the policy should be deleted when the policy is deleted. Pruning only takes place if the remediation action of the policy has been set to |
| Optional |
Specifies if and where to log the difference between the object on the cluster and the |
| Optional |
A list of objects that must be in specific compliance states before this policy is applied. Cannot be specified when |
| Required | The name of the object being depended on. |
| Optional | The namespace of the object being depended on. The default is the namespace of policies set for the Policy Generator. |
| Optional |
The compliance state the object needs to be in. The default value is |
| Optional |
The kind of the object. By default, the kind is set to |
| Optional |
The API version of the object. The default value is |
| Optional | The description of the policy you want to create. |
| Optional |
A list of objects that must be in specific compliance states before this policy is applied. The dependencies that you define are added to each policy template (for example, |
| Required | The name of the object being depended on. |
| Optional | The namespace of the object being depended on. By default, the value is set to the namespace of policies set for the Policy Generator. |
| Optional |
The compliance state the object needs to be in. The default value is |
| Optional |
The kind of the object. The default value is to |
| Optional |
The API version of the object. The default value is |
| Optional |
Bypass compliance status checks when the Policy Generator is waiting for its dependencies to reach their desired states. The default value is |
| Optional |
Automatically generate |
| Optional |
Automatically generate |
| Optional |
This determines if a single configuration policy is generated for all the manifests being wrapped in the policy. If set to |
| Optional |
Set |
| Optional |
When the policy references a Kyverno policy manifest, this determines if an additional configuration policy is generated to receive policy violations in Red Hat Advanced Cluster Management, when the Kyverno policy is violated. The default value is |
| Optional |
Labels that the policy includes in its |
| Optional |
Array of policy sets that the policy joins. Policy set details can be defined in the |
| Optional |
Generate placement manifests for policies. Set to |
| Optional |
When a policy is part of a policy set, by default, the generator does not generate the placement for this policy since a placement is generated for the policy set. Set |
| Optional | The placement configuration for the policies. This defaults to a placement configuration that matches all clusters. |
| Optional | Specifying a name to consolidate placements that contain the same cluster label selectors. |
| Optional |
Specify a placement by defining a cluster label selector using either |
| Optional |
Define this parameter to use a placement that already exists on the cluster. A |
| Optional |
To reuse an existing placement, specify the path relative to the location of the |
| Optional |
|
| Optional |
|
| Optional |
|
| Optional |
Default values for policy sets. Any default value listed for this parameter is overridden by an entry in the |
| Optional |
The placement configuration for the policies. This defaults to a placement configuration that matches all clusters. See |
| Optional |
Generate placement manifests for policy sets. Set to |
| Required |
The list of policies to create along with overrides to either the default values, or the values that are set in |
| Optional | The description of the policy you want to create. |
| Required | The name of the policy to create. |
| Required |
The list of Kubernetes object manifests to include in the policy, along with overrides to either the default values, the values set in this |
| Required |
Path to a single file, a flat directory of files, or a Kustomize directory relative to the |
| Optional |
A list of Kustomize patches to apply to the manifest at the path. If there are multiple manifests, the patch requires the |
| Optional |
Labels that the policy includes in its |
| Optional |
The list of policy sets to create, along with overrides to either the default values or the values that are set in |
| Required | The name of the policy set to create. |
| Optional | The description of the policy set to create. |
| Optional |
The list of policies to be included in the policy set. If |
4.1.4. Additional resources
- Read Generating a policy to install GitOps Operator.
- Read to Policy set controller for more details.
- Read Applying Kustomize for more information.
- Read the Governance documentation for more topics.
-
See an example of a
kustomization.yaml
file. - Refer to the Kubernetes labels and selectors documentation.
- Refer Gatekeeper for more details.
- Refer to the Kustomize documentation.
- Return to the Integrate third-party policy controllers documentation.
4.2. Generating a policy that installs the Compliance Operator
Generate a policy that installs the Compliance Operator onto your clusters. For an operator that uses the namespaced installation mode, such as the Compliance Operator, an OperatorGroup
manifest is also required.
Complete the following steps:
Create a YAML file with a
Namespace
, aSubscription
, and anOperatorGroup
manifest calledcompliance-operator.yaml
. The following example installs these manifests in thecompliance-operator
namespace:apiVersion: v1 kind: Namespace metadata: name: openshift-compliance --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: compliance-operator namespace: openshift-compliance spec: targetNamespaces: - openshift-compliance --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: compliance-operator namespace: openshift-compliance spec: channel: release-0.1 name: compliance-operator source: redhat-operators sourceNamespace: openshift-marketplace
Create a
PolicyGenerator
configuration file. View the followingPolicyGenerator
policy example that installs the Compliance Operator on all OpenShift Container Platform managed clusters:apiVersion: policy.open-cluster-management.io/v1 kind: PolicyGenerator metadata: name: install-compliance-operator policyDefaults: namespace: policies placement: labelSelector: matchExpressions: - key: vendor operator: In values: - "OpenShift" policies: - name: install-compliance-operator manifests: - path: compliance-operator.yaml
Add the policy generator to your
kustomization.yaml
file. Thegenerators
section might resemble the following configuration:generators: - policy-generator-config.yaml
As a result, the generated policy resembles the following file:
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement-install-compliance-operator namespace: policies spec: predicates: - requiredClusterSelector: labelSelector: matchExpressions: - key: vendor operator: In values: - OpenShift --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-install-compliance-operator namespace: policies placementRef: apiGroup: cluster.open-cluster-management.io kind: Placement name: placement-install-compliance-operator subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: install-compliance-operator --- apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: annotations: policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration policy.open-cluster-management.io/standards: NIST SP 800-53 policy.open-cluster-management.io/description: name: install-compliance-operator namespace: policies spec: disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: install-compliance-operator spec: object-templates: - complianceType: musthave objectDefinition: apiVersion: v1 kind: Namespace metadata: name: openshift-compliance - complianceType: musthave objectDefinition: apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: compliance-operator namespace: openshift-compliance spec: channel: release-0.1 name: compliance-operator source: redhat-operators sourceNamespace: openshift-marketplace - complianceType: musthave objectDefinition: apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: compliance-operator namespace: openshift-compliance spec: targetNamespaces: - compliance-operator remediationAction: enforce severity: low
As a result, the generated policy is displayed.