Skip to content

Latest commit

 

History

History
 
 

community

Policies -- Community

Policies in this folder are organized by NIST Special Publication 800-53. NIST SP 800-53 Rev 4 also includes mapping to the ISO/IEC 27001 controls. For more information, read Appendix H in NIST.SP.800-53r4.

Table of Contents

Security control catalog

Access Control

Policy Description Prerequisites
Disallowed roles policy Use the disallowed roles policy to make sure no pods are being granted full access in violation of least privilege. Check Using RBAC Authorization to learn more about Kubernetes RBAC authorization.
Disallowed anonymous authentication Use the disallowed anonymous authentication policy to make sure that the system:anonymous user and system:unauthenticated group are not associated with any ClusterRole / Role in the environment See the Gatekeeper documentation. Note: Gatekeeper controllers must be installed to use the gatekeeper policy.
Limit user bindings to ClusterRole This Gatekeeper Policy is intended to match the behavior of the deprecated ACM IAMPolicy Controller. It will allow an administrator to monitor and alert if ClusterRoleBindings with the specified ClusterRole exceed the maximum number of users. In the case where a Group is specified in the ClusterRoleBinding the number of users in the group are counted. ServiceAccounts are ignored. See the Gatekeeper documentation. Note: The Policy makes use of sync data from the cluster to have knowledge of the existing ClusterRoleBindings and Groups.
Configure RBAC for Application workloads Use this policy to configure a role based access control model for application workloads running on managed-clusters. This is a sample policy. This sample policy must be modified for your environment. Check Using RBAC Authorization to learn more about Kubernetes RBAC authorization.
Configure RBAC for Administering policies Use this policy to configure a role based access control model on the hub for administering policies in a multi team environment. Check Using RBAC Authorization to learn more about Kubernetes RBAC authorization.
Configure RBAC using groups in openshift for hub and managed clusters using admin and view-only roles Use this policy to configure a role based access control model on the hub to have a view-only access to desired managed clusters along with admin access to hub cluster based on groups to which the users belongs to. This sample policy must be modified for your environment, Check Using RBAC Authorization to learn more about Kubernetes RBAC authorization.

Awareness and Training

Policy Description Prerequisites
No policies yet

Audit and Accountability

Policy Description Prerequisites
Example of configuring audit logging with a policy Use policy-openshift-audit-logs-sample.yaml policy to configure audit logging in your OpenShift cluster. For example, you can deploy the policy to configure Elasticsearch to store the audit logs data and view them on Kibana console. See the OpenShift Documentation. This policy is only valid for OpenShift 4.6.x and needs to be adjusted for the proper environment.

Security Assessment and Authorization

Policy Description Prerequisites
Install Upstream Compliance Operator policy Use the upstream compliance operator installation, policy-comp-operator policy, to enable continuous compliance monitoring for your cluster. After you install this operator, you must select what benchmark you want to comply to, and create the appropriate objects for the scans to be run. See Compliance Operator for more details.
Check Fips-Compliance Use this policy to check if a Cluster has FIPS-Compliance-Enabled. This policy is only valid for OpenShift 4.6+. Read here for more information
Remove Kubeadmin Use this policy to remove the Kubeadmin-User from selected Clusters This policy is only valid for OpenShift 4.x Clusters

Configuration Management

Policy Description Prerequisites
Upgrade OpenShift-Cluster Sample policy Use this policy as an example for upgrading OpenShift clusters with a policy. OpenShift 4.x is required. In the provided example, a version 4.12 cluster is upgraded to version 4.12.17. Change the channel and the desired version if you want to upgrade other versions. The desired version.image field can be omitted if the target cluster has never been upgraded or was upgraded to a version that clears the field after a successful upgrade (some older versions do not). oc adm upgrade will list available version/image pairs in the current upgrade channel (the image used in the example is for OpenShift 4.12.17 on x86_64). If the version and image are mismatched, the image will take precedence.
Egress sample policy With the egress firewall you can define rules (per-project) to allow or deny traffic (TCP-or UDP) to the external network. OpenShift 4.x is required. See the OpenShift Security Guide. Use the OpenShift Security Guide to secure your OpenShift cluster.
Example of configuring a cluster-wide proxy with a policy Use this policy to configure a cluster-wide proxy. OpenShift 4.x is required. See the OpenShift Documentation. This policy is only valid for OpenShift 4.x and needs to be adjusted for the proper environment. You should not include passwords in a policy. Use the templatized policy feature to avoid including the proxy password in the policy.
Example of configuring DNS with a policy Use this policy to configure DNS in your OpenShift cluster. For example, you can remove public DNS. OpenShift 4.x is required. See the OpenShift Documentation This policy is only valid for OpenShift 4.x and needs to be adjusted for the proper environment.
Example of configuring the Cluster Network Operator with a policy Use this policy to configure the network of your OpenShift cluster. OpenShift 4.x is required. See the OpenShift Documentation. This policy is only valid for OpenShift 4.x and needs to be adjusted for the proper environment.
Example of creating a deployment object This example generates 3 replicas of `nginx-pods`. See the Kubernetes Documentation to learn more about Deployments.
Example of creating a zts-cmc deployment object This example deploys a replica of `zts-cmc-pod`. See the Zettaset README to learn more about Zettaset CMC Deployment.
policy-zts-xcrypt-rbac This example deploys RBAC for `zts-xcrypt-deployment`. See the [Zettaset README.stable(https://github.com/zettaset/zettaset-public/) to learn more about Zettaset Xcrypt Deployment.
policy-zts-xcrypt-deployment This example deploys `zts-xcrypt-deployment`. See the [Zettaset README.stable(https://github.com/zettaset/zettaset-public/) to learn more about Zettaset Xcrypt Deployment.
Example of a policy used to configure GitHub-Authentication Use this policy to log in to your OpenShift cluster with GitHub-Authentication. OpenShift 4.x is required. See the OpenShift Documentation, Configuring a GitHub or GitHub Enterprise identify provider to learn more information about identity providers. You must modify the contents of this policy so that it is applicable to your environment.
Example of installing Performance Addon Operator Use this policy to install the Performance Addon Operator, which provides the ability to enable advanced node performance tunings on a set of nodes. OpenShift 4.x is required. See the RHACM & Performance Addon Operator repository documentation for more details.
Example of installing PTP Operator Use this policy to install the Precision Time Protocol (PTP) Operator, which creates and manages the linuxptp services on a set of OpenShift nodes. OpenShift 4.x is required. See the RHACM & PTP Operator repository documentation for more details.
Example of installing the Red Hat Serverless Operator Use this policy to install the OpenShift serverless Operator. See the About OpenShift Serverless for more details.
Example of installing SR-IOV Network Operator Use this policy to install the Single Root I/O Virtualization (SR-IOV) Network Operator, which manages the SR-IOV network devices and network attachments in your clusters. OpenShift 4.x is required. See the RHACM & SR-IOV Network Operator repository documentation for more details.
Example of labeling nodes of a cluster Use this policy to label nodes in your managed clusters. Notice you must know the name of the node or nodes to label. OpenShift 4.x is required. See the OpenShift Documentation to learn more about labelling objects.
Example to configure an image policy Use the image policy to define the repositories from where OpenShift can pull images. OpenShift 4.x is required. Refer to the chapter named Container Image Security in the OpenShift Security Guide. for more information. You must customize the contents of this policy.
Gatekeeper operator policy Use the Gatekeeper operator policy to install the community version of Gatekeeper on a managed cluster. See the Gatekeeper Operator.
Gatekeeper config exclude namespaces Use the Gatekeeper policy to exclude namespaces from certain processes for all constraints in the cluster See the gatekeeper documentation exempting-namespaces-from-gatekeeper for more information. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy.
Gatekeeper container image with the latest tag Use the Gatekeeper policy to enforce containers in deployable resources to not use images with the latest tag. See the Gatekeeper documentation. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy.
Gatekeeper liveness probe not set Use this Gatekeeper policy to make sure pods have a liveness probe. See the Gatekeeper documentation. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy.
Gatekeeper readiness probe not set Use this Gatekeeper policy to make sure pods have a readiness probe. See the Gatekeeper documentation. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy.
Gatekeeper allowed external IPs Use the Gatekeeper allowed external IPs policy to define external IPs that can be specified by Services. See the Gatekeeper. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy.
Gatekeeper sample policy Use the Gatekeeper sample policy to view an example of how a gatekeeper policy can be applied to a managed cluster. This sample requires a gatekeeper label to be applied to a list of namespaces. See the Gatekeeper. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy.
Gatekeeper mutation policy (owner annotation) Use the Gatekeeper mutation policy to set the owner annotation on pods. See the Gatekeeper. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy. You must enable mutatingWebhook to use the gatekeeper mutation feature.
Gatekeeper mutation policy (image pull policy) Use the Gatekeeper mutation policy to set or update image pull policy on pods. See the Gatekeeper. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy. You must enable mutatingWebhook to use the gatekeeper mutation feature.
Gatekeeper mutation policy (termination GracePeriodSeconds) Use the Gatekeeper mutation policy to set or update the termination grace period seconds on pods. See the Gatekeeper. Note: Gatekeeper controllers must be installed to use the gatekeeper policy. See the Gatekeeper operator policy. You must enable mutatingWebhook to use the gatekeeper mutation feature.
MachineConfig Chrony sample policy Use the MachineConfig Chrony policy to configure /etc/chrony.conf on certain machines. OpenShift 4.x is required. For more information see, Modifying node configurations in OpenShift 4.x blog.
Network-Policy-Samples Use the Network policy to specify how groups of pods are allowed to communicate with each other and with other network endpoints. See the OpenShift Security Guide. Note: The policy might be modified to the actual usecases.
OPA sample policy Use the Open Policy Agent (OPA) Sample policy to view an example of how an OPA policy can be created. You can also view an example of adding a REGO script into a ConfigMap, which is evaluated by the OPA. See the OPA example repository. Note: OPA must be installed to use the OPA ConfigMap policy.
Trusted Container policy Use the trusted container policy to detect if running pods are using trusted images. This policy requires a custom controller to be deployed. See the Trusted Container Policy Controller for details on the custom controller.
Trusted Node policy Use the trusted node policy to detect if there are untrusted or unattested nodes in the cluster. This policy requires a custom controller to be deployed. See the Trusted Node Policy Controller for details on the custom controller.
ETCD Backup Use the ETCD Backup policy to receive the last six backup snapshots for etcd. This policy uses the etcd container image in the policy because it contains all required tools like etcdctl. OpenShift 4.x is required. For more information, see OpenShift 4 with default storage class.
Integrity Shield Use the Integrity Shield to protect the integrity of Kubernetes resources in a cluster (e.g. OpenShift). See the Integrity Shield documentation.
Integrity Shield Events Use the Integrity Shield Events policy to show a status, which represents whether Integrity Shield has denied some requests in a cluster or not. See the Integrity Shield documentation.
Integrity Shield Observer Integrity Shield Observer continuously verifies Kubernetes resource on cluster according ManifestIntegrityConstraint resources and exports the results to resources called ManifestIntegrityState. This policy is used to alert on any resource signature violations that have been identified by the observer. This policy does not install Integrity Shield. This policy does require Integrity Shield to already be installed. See the Integrity Shield documentation.
v1alpha2 PolicyReport failures This policy searches for any PolicyReport resources that contain failures in the results. An example of a tool that creates PolicyReports is Kyverno. Be aware that the PolicyReports API is an alpha API and multiple versions may be available. A policy using the v1alpha1 API is v1alpha1 PolicyReport failures.
Kyverno sample policy Use the Kyverno sample policy to view an example of how a kyverno policy can be applied to a managed cluster. This policy is evaluated by the kyverno controller on a managed cluster. This policy requires all pods to have a certain label defined. Note that you cannot create pods that do not have this label if you apply this policy. See the Installation instructions and How to write Kyverno policies. Note: Kyverno must be installed on the managed clusters to use the Kyverno policy.
OpenShift Kernel Configuration Use this policy to create OpenShift 4 machine configurations that install kernel development packages. The kernel development packages are needed for the Sysdig and Falco agents to integrate into the host kernel. This policy is only valid for OpenShift 4.x.
Volsync Persistent Data Replication Use this policy to deploy the Volsync controller. Once the controller has been deployed, replication source and replication destination objects can be created allowing for persistent volume claims to be replicated. See the VolSync Replication documentation for more information.
Setup-Subscription-Admin Use this policy to activate the Subscription-Admin feature in RHACM See this Solution for more information about this feature https://access.redhat.com/solutions/6010251
Configure-Logforwarding Use this policy to configure Logforwarding. OpenShift 4.x is required. See this blog for more information about this example
Install OpenShift-Update-Service Use this policy to install the OpenShift Update Service. This policy is only valid for OpenShift 4.6+. Read the documentation for more information
Install OpenShift-Gitops Use this policy to install the Red Hat OpenShift GitOps operator which can be used to install and configure Gitops, Tekton and ArgoCD Requires OpenShift 4.x. Check the documentation for more information.
Configure OpenShift-Gitops with the Policy Generator Use this policy to configure the Red Hat OpenShift GitOps operator to run the policy generator Requires OpenShift 4.x and requires the Openshift GitOps operator to be installed. Check the documentation for more details.
Configure OpenShift Image-Pruner Use this policy to configure the OpenShift Image-Pruner OpenShift 4.x is required. Check the documentation for more information
Policy to configure a POD Disruption Budget use this policy to configure a Pod Disruption Budget Check Kubernetes documentation for more information
Policy to configure a cluster autoscaler Use this policy to configure a ClusterAutoscaler. OpenShift 4.x is required. Check the OpenShift documentation for more information.
Policy to configure Ingress Controller Use this policy to configure the IngressController OpenShift 4.x is required. Check the OpenShift documentation for more information on how to customize this policy.
Policy to configure the Scheduler Use this policy to configure the OpenShift Scheduler OpenShift 4.x is required. Check OpenShift documentation for more information
Policy to install the Red Hat Single Sign-On Operator Use this policy to install the Red Hat Single Sign-On Operator OpenShift 4.x is required. Check the documentation for more information
Policy to install External-Secrets Use this policy to install External Secrets. Kubernetes External Secrets allows you to use external secret management systems, like AWS Secrets Manager or HashiCorp Vault, to securely add secrets in Kubernetes. Check the documentation and this solution for more information.
Policy to install the Red Hat Advanced Cluster Security Central Server Use this policy to install the Red Hat Advanced Cluster Security operator to the Open Cluster Management hub and install the Central Server to the stackrox namespace. OpenShift 4.x is required. For more information on Red Hat Advanced Cluster Security, visit Red Hat Advanced Cluster Security for Kubernetes
Policy to install the Red Hat Advanced Cluster Security Secure Cluster Services Use this policy to install the Red Hat Advanced Cluster Security operator to all OpenShift managed clusters and install the Secure Cluster Services to the stackrox namespace. OpenShift 4.x is required. For more information on Red Hat Advanced Cluster Security, visit Red Hat Advanced Cluster Security for Kubernetes. This policy requires policy template support to be available in Red Hat Advanced Cluster Management for Kubernetes version 2.3. See advanced-cluster-security for additional prerequisites needed for installing this policy.
Policy to install cert-manager Use this policy to deploy the community operator for cert-manager which installs cert-manager on OpenShift clusters. For more information on cert-manager visit Cloud native certificate management
Policy to label a Managed-Cluster Use this policy to label a Managed-Cluster Open Cluster Management is required. This policy needs to be applied on the Managing-Cluster, adjust the labels to your needs
Policy to set a Config-Map with properties for different environments Use this policy to configure a policy for different environments Adjust this example for your needs
Policy to install Local Storage Operator Use this policy to install and configure the Local Storage Operator Add the LocalVolumeSet and LocalVolume resources to your policy as necessary for your needs
Policy to define a Custom CatalogSource Use this policy to configure or patch a Custom CatalogSource OpenShift 4.x is required. Consult the documentation for more information
Policy to install the ansible-awx-operator Use this policy to configure the ansible-awx-operator to allow AnsibleJobs to be processed. Archived: This policy is needed for Ansible integration on OpenShift 4.8 and older. Use the Ansible Automation Platform operator policy as a replacement for this operator.
Policy to install the Ansible Automation Platform operator Use this policy to install Ansible Automation Platform operator, automation hub and controller Requires OpenShift 4.x. This operator is needed to process AnsibleJobs. See the Red Hat Ansible Automation Platform for more details.
Policy to configure ClusterLogForwarding using Template-Feature Use this policy to configure ClusterLogForwarding to send audit logs to a Kafka-Topic. Every Cluster gets it's own topic because of the new Templatized-Feature. To validate the configuration, run the following command: oc get ClusterLogForwarder instance -n openshift-logging -oyaml. The minimum prerequisites are OpenShift 4.6 and RHACM 2.3
Policy to add OpenShift APIs for Data Protection (OADP) Use this policy to install the OADP operator and data protection application (DPA) A cloud-credentials secret should be created with credentials for the S3 bucket. Review documentation for more information.
Policy to setup ODF Use this policy to install and configure the OpenShift Data Foundation making it work would require e.g. on AWS m5 instances would be required. Requires OpenShift 4.6 or later.
Policy to install Kyverno's Helm Chart Use this policy to install Kyverno Consult Kyverno on GitHub to get more information about Kyverno.
Policy to install Kyverno operator Use this policy to install Kyverno's OLM Operator on OpenShift Consult Kyverno on GitHub to get more information about Kyverno.
Kyverno config exclude resources Use this Kyverno policy to exclude resources from certain processes for all constraints in the cluster See the Resource Filters from the Kyverno documentation. Note: Kyverno controller must be installed to use the kyverno policy. See Policy to install Kyverno.
Kyverno mutation policy (image pull policy) Use the Kyverno mutation policy to set or update the image pull policy on pods See the Kyverno project. Note: Kyverno controller must be installed to use the kyverno policy. See the Policy to install Kyverno.
Kyverno mutation policy (termination GracePeriodSeconds) Use the Kyverno mutation policy to set or update the termination grace period seconds on pods See the Kyverno project. Note: Kyverno controller must be installed to use the kyverno policy. See the Policy to install Kyverno.
Policy to install ArgoCD on Non-OpenShift Clusters Use this policy to install ArgoCD on Kubernetes. This policy deploys ArgoCD as a Helm Chart and can be applied to non OpenShift clusters.
Policy to create a CronJob installing oc-client Use this policy to execute custom commands using oc-client There are several examples where you might need to setup custom commands. You must customize the commands you want to run in the policy. To learn more visit Kubernetes CronJob documentation
Scan your cluster with the OpenShift Moderate security profile This example creates a ScanSettingBinding that the Compliance Operator uses to scan the cluster for compliance with the OpenShift FedRAMP Moderate benchmark. The Compliance Operator can only scan OpenShift nodes. For more details, visit: Understanding the Compliance Operator.
Scan your cluster with the OpenShift High security profile This example creates a ScanSettingBinding that the Compliance Operator uses to scan the cluster for compliance with the OpenShift NIST 800-53 High benchmark. The Compliance Operator can only scan OpenShift nodes. For more details, visit: Understanding the Compliance Operator.
Scan your cluster with the OpenShift PCI-DSS security profile This example creates a ScanSettingBinding that the Compliance Operator uses to scan the cluster for compliance with the PCI-DSS v3.2.1 Control Baseline for Red Hat OpenShift Container Platform 4. The Compliance Operator can only scan OpenShift nodes. For more details, visit: Understanding the Compliance Operator.
Scan your cluster with the OpenShift NERC-CIP security profile This example creates a ScanSettingBinding that the Compliance Operator uses to scan the cluster for compliance with the North American Electric Reliability Corporation (NERC) Critical Infrastructure benchmark. The Compliance Operator can only scan OpenShift nodes. For more details, visit: Understanding the Compliance Operator.
Scan control plane components of HyperShift hosted cluster using tailored CIS Benchmark for OpenShift profile This example creates a TailoredProfile designed to scan control plane components of a HyperShift hosted cluster in addition to ScanSetting and ScanSettingBinding to invoke a scan using the TailoredProfile. The Compliance Operator can only scan OpenShift nodes. For more details, visit: Understanding the Compliance Operator.
Policy to customize OpenShift OAuth tokens Use this policy to configure the OpenShift tokens to expire after a set period of inactivity. OpenShift 4.x is required. For more information on configuring the OAuth clients, see the OpenShift documentation: Configurating the internal oauth Server
Policy to install IDP operator Use this policy to install Identity configuration management operator. For more information on this operator, see the IDP documentation. NOTE: See the IDP requirements and recommendations before using this policy.
Policy to configure Github identity provider in IDP Use this policy to apply Github OAuth to managed clusters through IDP . For more information on this operator, see the IDP documentation: Identity configuration management for Kubernetes. NOTE: IDP Operator must be installed before using this policy.
Policy to install the OpenShift File Integrity operator Use the File Integrity Operator to continually run file integrity checks on the cluster nodes. This policy becomes NonCompliant when a FileIntegrityNodeStatus returns a status of Failed, which indicates files on the nodes have changed. OpenShift 4.x is required. See Understanding the File Integrity Operator for more details.
Policy to install AWS MachineSets on OpenShift This policy creates 3 OpenShift MachineSets that are intended for installing OpenShift Cluster Storage on AWS. OpenShift 4.x is required. These MachineSets also require AWS and contain image IDs that are specific to OpenShift 4.9. Update the AMI ids in the policy prior to use. See the comments in the policy for additional details.
Policy to install RHODA Operator on OpenShift This policy creates Red Hat OpenShift Database Access Operator on managed clusters and hub clusters allow users to onnect to managed databases from their apps deployed in OpenShift. OpenShift 4.10 is required. Consult the documentation for more information
Policy to install and configure the ODF LVM Operator Use this policy to install and configure the Openshift Data Foundation LVM Operator Requires OpenShift 4.10 or later. Nodes must have additional disks that will be used to provide storage.
Policy to configure a ManagedClusterSetBinding Use this policy to create a namespace named policies and bind it to the ClusterSet named default. This allows policies created in that namespace to use the cluster placement with any managed clusters in the default cluster set. This policy should only be placed on the hub cluster.
Policy to install the Red Hat Web Terminal Operator OpenShift 4.10 or newer is required. See About the web terminal in the web console for more details.
Policy to configure proxy protocol See Configuring the PROXY protocol for more details.
Policy to install Trilio for Kubernetes Operator Use this policy to install Trilio for Kubernetes Operator on Openshift clusters with label "protected-by=triliovault" Requires OpenShift 4.8 or later. Needs CSI Driver with snapshot capabilities, storageClass and volumeSnapshotClass. For more information, refer documentation
Policy to create namespace based backup using Triliovault for Kubernetes Use this policy to create namespace based backup using Triliovault for Kubernetes on Openshift clusters with label "protected-by=triliovault" Requires OpenShift 4.8 or later. Note: Triliovault for Kubernetes must be installed to use this policy. See the Policy to install Triliovault for Kubernetes Operator. On the hub cluster, create a secret "aws-s3-secret" with S3 credentials and a configmap "aws-s3-configmap" with S3 bucket name, region name, thresholdCapacity & namespace name for backup in the namespace on the hub cluster where this policy is created (details given in the policy). For more information, refer documentation
Policy to create namespace based backup using Triliovault for Kubernetes and kyverno template Use this policy to create namespace based backup using Triliovault for Kubernetes and kyverno template on Openshift clusters with label "protected-by=triliovault". It creates backup of the namespaces having a label "protected-by=tvk-ns-backup" Requires OpenShift 4.8 or later. Note: Kyverno controller must be installed to use the kyverno policy. See the Policy to install Kyverno. Triliovault for Kubernetes must be installed to use this policy. See the Policy to install Triliovault for Kubernetes Operator. On the hub cluster, create a secret "aws-s3-secret" with S3 credentials and a configmap "aws-s3-configmap" with S3 bucket name, region name & thresholdCapacity in the namespace where this policy is created (details given in the policy). For more information, refer documentation
policy-pod-placement Ensures that a pod exists as specified. This policy uses the Placement kind rather than a PlacementRule to select managed clusters to deploy to.
Policy checking for ConfigurationPolicies stuck in a Terminating state Notifies that a ConfigurationPolicy was not able to delete some objects from its PruneObjectBehavior setting. Those related objects, and/or the ConfigurationPolicy might need to be manually cleaned up.
Policy to add node to an existing ACM cluster Adds a new node to an existing ZTP cluster in ACM. Useful to scale capacity to existing clusters as a day 2 operation. This policy will apply to the hub cluster and deploy a new BareMetalHost resource in the managed cluster's namespace. The multicluster-engine operator must be set up and configured on the hub cluster. This policy assumes that DHCP is available for the node to obtain network information. BMH secrets must be created separately.
Policy to add node wtih static IP configurations to an existing ACM cluster Adds a new node with a Static IP to an existing ZTP cluster in ACM. Useful to scale capacity to existing clusters as a day 2 operation. This policy will apply to the hub cluster and deploy new BareMetalHost and NMStateConfig resources in the managed cluster's namespace. The multicluster-engine operator must be set up and configured on the hub cluster. BMH secrets must be created separately.
Policy to create a MachineSet for infrastructure nodes on a vSphere environment Adds a new MachineSet for infrastructure nodes by using a vSphere cloud provider. This policy creates the virtual machines in the vCenter and adds the machines to the OpenShift cluster. OpenShift 4.x is required. For more information on creating infrastructure machine sets, see the OpenShift documentation: Creating infrastructure machine sets
Policy to configure the OAuth in OpenShift and sync with LDAP Adds some objects to configure the OAuth in a OpenShift cluster by using an external LDAP (Active Directory in this example). In addition to this, a CronJob is created to sync the OpenShift cluster with an external LDAP. OpenShift 4.x is required. For more information on configuring the OAuth clients, see the OpenShift documentation: Configuring the LDAP identity provider
Policy to configure the htpasswd identity provider in OpenShift Adds some objects to configure the OAuth in a OpenShift cluster by using htpasswd identity provider. OpenShift 4.x is required. For more information on configuring the OAuth clients, see the OpenShift documentation: Configuring an htpasswd identity provider
Policy to install and configure OpenShift Service Mesh Adds some objects to install OpenShift Service Mesh in Openshift Container Platform, and configure a basic Service Mesh. OpenShift 4.x is required. For more information on installing and configuring OpenShift Service Mesh, see the OpenShift documentation: Service Mesh 2.x
Policy to install Triliovault for Kubernetes using Helm chart Use this policy to install Triliovault for Kubernetes using Helm chart on any (non-Openshift) clusters with label "protected-by=triliovault" Needs CSI Driver with snapshot capabilities, storageClass and volumeSnapshotClass. For more information, refer documentation
Policy to deploy trial license for Triliovault for Kubernetes deployed using Helm chart Use this policy to deploy trial license for Triliovault for Kubernetes deployed using Helm chart on any (non-Openshift) clusters with label "protected-by=triliovault". Note: Triliovault for Kubernetes must be installed using Policy to install Triliovault for Kubernetes using Helm chart. For more information, refer documentation
Policy to create label based backup using Triliovault for Kubernetes Use this policy to create label based backup using Triliovault for Kubernetes on any clusters with label "protected-by=triliovault" In case of OpenShift, requires 4.8 or later. Note: Triliovault for Kubernetes must be installed to use this policy. See the Policy to install Triliovault for Kubernetes Operator. On the hub cluster, create a secret "aws-s3-secret" with S3 credentials and a configmap "aws-s3-configmap" with S3 bucket name, region name, thresholdCapacity, application label for backup & the namespace on the hub cluster where this policy is created (details given in the policy). For more information, refer documentation
Policy to create helm based backup using Triliovault for Kubernetes Use this policy to create helm based backup using Triliovault for Kubernetes on any clusters with label "protected-by=triliovault" In case of OpenShift, requires 4.8 or later. Note: Triliovault for Kubernetes must be installed to use this policy. See the Policy to install Triliovault for Kubernetes Operator. On the hub cluster, create a secret "aws-s3-secret" with S3 credentials and a configmap "aws-s3-configmap" with S3 bucket name, region name, thresholdCapacity, backup namespace & the helm release for backup on the hub cluster where this policy is created (details given in the policy). For more information, refer documentation
Policy to create operator based backup using Triliovault for Kubernetes Use this policy to create namespace based backup using Triliovault for Kubernetes on any clusters with label "protected-by=triliovault" In case of OpenShift, requires 4.8 or later. Note: Triliovault for Kubernetes must be installed to use this policy. See the Policy to install Triliovault for Kubernetes Operator. On the hub cluster, create a secret "aws-s3-secret" with S3 credentials and a configmap "aws-s3-configmap" with S3 bucket name, region name, thresholdCapacity & backup namespace on the hub cluster where this policy is created. Also note that this configmap needs to updated with Operator details such as Operator ID, operator Resources Label-value and Operator Application Label-value (details given in the policy). For more information, refer documentation
Policy to create event target for continuous restore using Triliovault for Kubernetes 1st of total 3 policies for setting up Continuous Restore, use this policy to create event target on 2 clusters (source and target) participating in the Continuous Restore Functionality defined with labels "protected-by=triliovault" and "tvk-continuous-restore=enabled" In case of OpenShift, requires 4.8 or later. Note: Triliovault for Kubernetes must be installed on both the clusters to use this policy. See the Policy to install Triliovault for Kubernetes Operator. On the hub cluster, create a secret "aws-s3-secret" with S3 credentials and a configmap "aws-s3-configmap" with S3 bucket name, region name & thresholdCapacity on the hub cluster where this policy is created (details given in the policy). For more information, refer documentation
Policy to create backup for continuous restore using Triliovault for Kubernetes 2nd of total 3 policies for setting up Continuous Restore, use this policy to create backup on the source cluster participating in the Continuous Restore Functionality defined with labels "protected-by=triliovault" and "tvk-continuous-restore-cluster=source" In case of OpenShift, requires 4.8 or later. Note: Triliovault for Kubernetes must be installed to use this policy. See the Policy to install Triliovault for Kubernetes Operator. Must deploy 1st policy for setting up Continuous Restore to create event target, see Policy to create event target for continuous restore using Triliovault for Kubernetes. On the hub cluster, create a configmap tvk-cr-backup-configmap with backup namespace (details given in the policy). For more information, refer documentation
Policy to create restore from continuous restore using Triliovault for Kubernetes 3rd of total 3 policies for setting up Continuous Restore, use this policy to recover the application backed up from the source cluster to the target cluster participating in the Continuous Restore Functionality. The target cluster i defined with labels "protected-by=triliovault" and "tvk-continuous-restore-cluster=target". In case of OpenShift, requires 4.8 or later. Note: Triliovault for Kubernetes must be installed to use this policy. See the Policy to install Triliovault for Kubernetes Operator. Must deploy 1st policy for setting up Continuous Restore to create event target, see Policy to create event target for continuous restore using Triliovault for Kubernetes and 2nd policy to create backup Policy to create backup for continuous restore using Triliovault for Kubernetes. On the hub cluster, create a configmap tvk-cr-restore-configmap with restore namespace (details given in the policy). For more information, refer documentation
Policy to install Red Hat Single Sign-On (RHSSO) operator 1st of total 4 policies for configuring Red Hat Single Sign-on(RHSSO) across OCM managed clusters, use this policy to install RHSSO operator v7.6.2. For more information, see Red Hat Single Sign-On Operator documentation
Policy to setup Red Hat Single Sign-On (RHSSO) for OCM 2nd of total 4 policies for configuring Red Hat Single Sign-on (RHSSO) across OCM managed clusters, use this policy to stand up an instance of KeyCloak on the hub cluster and an authentication realm for use by OCM managed clusters. Note: Additional configuration of installed Keycloak instance e.g Authentication flow type or Setup of external IDPs like Github IDP etc need to performed directly in the KeyCloak console, for more information, see Red Hat Single Sign-On Operator documentation
Policy to configure Red Hat Single Sign-on(RHSSO) for OCM managed cluster - Hub artifacts 3rd of total 4 policies for configuring Red Hat Single Sign-on (RHSSO) across OCM managed clusters, use this policy to set up hub side artifacts required to configure Red Hat Single Sign-on IDP on the managed clusters. For more information, see Red Hat Single Sign-On Operator documentation
Policy to configure Red Hat Single Sign-on (RHSSO) for OCM managed cluster - Spoke artifacts 4th of total 4 policies for configuring Red Hat Single Sign-on (RHSSO) across OCM managed clusters, use this policy to set up spoke side artifacts required to configure Red Hat Single Sign-on IDP on the managed clusters. For more information, see Red Hat Single Sign-On Operator documentation, also see Openshift OpenID IDP documentation
Policy to install and configure OADP operator for stateful application backup First of 3 policies, used to backup or restore stateful applications on managed clusters. Used to install OADP on managed clusters and configure the connection to the storage location and installed on both backup and restore operations. For more information, see ACM Application Backup and Restore policy readme
Policy to backup a stateful application with OADP Second of 3 policies, used to backup stateful applications on managed clusters. For more information, see ACM Application Backup and Restore policy readme
Policy to restore a stateful application with OADP Last of 3 policies, used to restore stateful applications on managed clusters. For more information, see ACM Application Backup and Restore policy readme
Policy to automatically import ROSA clusters Use this policy to automatically import discovered ROSA clusters as a managed cluster. By default this policy will configure ROSA discovered clusters to be automatically imported as a managed cluster. Edit the ConfigMap to adjust the discovered cluster filter. Edit the managed cluster resource to change the default ManagedClusterSet the mananged cluster is added to.
Policy to automatically import MultiClusterEngine HCP clusters Use this policy to automatically import discovered MultiClusterEngine HCP clusters as a managed cluster. By default this policy will configure MultiClusterEngine HCP discovered clusters to be automatically imported as a managed cluster. Edit the ConfigMap to adjust the discovered cluster filter. Edit the managed cluster resource to change the default ManagedClusterSet the mananged cluster is added to.
Kyverno Generate Network Policies Configures a new NetworkPolicy resource named default-deny which will deny all traffic anytime a new Namespace is created. See the Kyverno project. Note: Kyverno controller must be installed to use the kyverno policy. See the Policy to install Kyverno in the community folder.
Kyverno Generate Quota Configures new ResourceQuota and LimitRange resources anytime a new Namespace is created. See the Kyverno project. Note: Kyverno controller must be installed to use the kyverno policy. See the Policy to install Kyverno in the community folder.
Kyverno Sync Secrets This policy will copy a Secret called regcred which exists in the default Namespace to new Namespaces when they are created and it will keep the secret updated with changes. See the Kyverno project. Note: Kyverno controller must be installed to use the kyverno policy. See the Policy to install Kyverno in the community folder.

Contingency Planning

Policy Description Prerequisites
No policies yet

Identification and Authentication

Policy Description Prerequisites
No policies yet

Incident Response

Policy Description Prerequisites
No policies yet

Maintenance

Policy Description Prerequisites
No policies yet

Media Protection

Policy Description Prerequisites
No policies yet

Physical and Environmental Protection

Policy Description Prerequisites
No policies yet

Planning

Policy Description Prerequisites
No policies yet

Personnel Security

Policy Description Prerequisites
No policies yet

Risk Assessment

Policy Description Prerequisites
No policies yet

System and Services Acquisition

Policy Description Prerequisites
No policies yet

System and Communications Protection

Policy Description Prerequisites
OpenShift Certificate Expiration Policy Monitor the OpenShift 4.x namespaces to validate that certificates managed by the infrastructure are rotated as expected. OpenShift 4.x is required.
OpenShift Cluster Operator state policy This policy alerts when an OpenShift ClusterOperator becomes unhealthy. See ClusterOperator config for additional details. OpenShift 4.x only.
Check namespaces in Terminating status check for namespaces in terminating status check e.g. this link how to fix this.
Disable self-provisioner Disable ability to for users to create their own projects OpenShift 4.x only.

System and Information Integrity

Policy Description Prerequisites
Falco Cloud-Native runtime security Operator install Falco parses Linux system calls from the kernel at runtime, and asserts the stream against a powerful rules engine. If a rule is violated, a Falco alert is triggered. Archived: Install Falco using the Falco helm install since the operator is not being updated. The Falco Project. If the agent fails to integrate with an OpenShift host kernel, install the policy OpenShift Kernel Configuration.
Falco Cloud-Native runtime security Helm install Falco parses Linux system calls from the kernel at runtime, and asserts the stream against a powerful rules engine. If a rule is violated, a Falco alert is triggered. The Falco Project. If the agent fails to integrate with an OpenShift 4.x host kernel, install the policy OpenShift Kernel Configuration.
OpenShift Auditing for Falco Falco can also parse Kubernetes audit events and trigger alerts when auditing rules are violated. Use this policy to enable sending audit events to falco on OpenShift clusters. The Falco Project.
Sysdig Agent The Sysdig Secure DevOps Platform converges security and compliance with performance and capacity monitoring to create a secure DevOps workflow. It uses the same data to monitor and secure, so you can correlate system activity with Kubernetes services. Check Sysdig and start a Free Trial. If the agent fails to integrate with an OpenShift 4.x host kernel, install the OpenShift Kernel Configuration policy.
Black Duck Connector By integrating Black Duck with Kubernetes and OpenShift, you can automatically scan, identify, and monitor all your container images to gain visibility into, and control over, any security vulnerabilities or policy violations found in the open source code that exists in your containers. Check out Black Duck for OpenShift and read more.
CrowdStrike Falcon Operator install The CrowdStrike Falcon operator makes it easy to install and deploy CrowdStrike Falcon Sensors to run CrowdStrike Falcon Cloud Workload Protection to the control-plane and worker nodes running Red Hat Red Hat Enterprise Linux CoreOS (RHCOS) on Red Hat OpenShift 4. This allows customers to deploy and manage applications with a singular view across cloud environments, ensuring multi-cluster consistency and security. Checkout CrowdStrike's Cloud Workload Protection and learn more.

Templatized Policies

The following sample policies demonstrate the use of templatization feature to build flexible policies

Policy Description Prerequisites
Configure Deployment Configures nginx deployment resource customized to the target cluster based on contents of resources on the target managedcluster , template-type: managedcluster, template-functions : fromClusterClaim, fromSecret, eq, if-else Go Templates functions
Configure PodDisrution Budget Configures a pod disruption budget resource with the values customized based on whether the target managedcluster is labeled a prod environment, template-type: managedcluster, template-functions : lookup, eq, if-else Go Templates functions
Configure Cluster Info Configures a clusterinfo configmap which contains information about the target managedcluster e.g. its ocp-version etc , template-type: managedcluster, template-functions : fromClusterClaim Go Templates functions
Configure ClusterAutoScaler Using hub templates configures the ClusterAutoScaler resource with values customized to the target cluster , template-type: hub, template-functions : fromConfigMap, .ManagedClusterName Go Templates functions
Enable Policy If Namespace exists Demos enabling one policy from another based on existence of a namespace, template type: managedcluster, template functions : lookup, ne, toBool Go Templates functions
Enable Policy If EtcdEncryption is set Enables one policy from another based on whether etcd encryption is setup, template type: managedcluster, template functions : lookup, ne, toBool Go Templates functions
Configure SriovNetwork Using hub templates configures the SriovNetwork resource with values customized to the target cluster , template-type: hub, template-functions : fromConfigMap, .ManagedClusterName Sriov Network Operator , Go Templates functions

Deploying community policies to your cluster

While the policies in the stable folder all have out-of-the-box support installed with Red Hat Advanced Cluster Management, community policies are maintained by the open source community. You might need to deploy extra policy consumers in order for community policies to work as intended. If you are seeing the error no matches for kind "<resource name>" in version "<group>/<version>", you must deploy the CustomResourceDefinition (CRD) for the policy before you create it. If some of the policies in this folder are not behaving properly, you must deploy the corresponding policy consumers to handle them.

Custom policy controllers

Custom policy controllers are created from forks of the sample policy controller repo, and as such the process for deploying them is essentially the same as the process for deploying the sample controller.

  • Run the following command on your cluster to install the CRD for the custom policy: kubectl apply -f <CRD path>
  • Run the following command to set up the operator and service account that runs the controller on your cluster: kubectl apply -f deploy/

Policy consumers on operator hub

Some policy consumers are packaged as operators and are available on the Operator hub. These consumers can simply be deployed by creating a policy with child configuration policies to handle the installation. The configuration policies might include the following information:

  • A namespace to deploy the operator on, if necessary
  • A ClusterServiceVersion with install capabilities to install the operator from the operator hub
  • A OperatorGroup
  • A Subscription
  • The custom resource defined by the consumer to enforce custom policies For more specific examples of this method of deploying a policy consumer from the operator hub, see the Policy to install cert-manager and the Ansible Automation Platform operator.

Other custom policy consumers

Occasionally, policies in this folder might be consumed by controllers that do not fall into either of the two categories previously mentioned. To get the most out of these policies, see the Security control catalog