As customers transition from traditional IT infrastructure to cloud based environments, one of the key challenges they need to address is meeting the requirements of enterprise internal standards, external standards, and regulatory compliance standards. These requirements apply to multiple aspects such as security, resiliency, and software engineering. The subject matter expert for a technology in question knows how it needs to be configured to meet such requirements and best practices, but the Site Reliability Engineer (SRE) and or Operations personnel are not necessarily an expert in all these aspects. This is where applying policy based governance as outlined in the blogs, Comply to standards using policy-based governance of Red Hat Advanced Cluster Managment and Implement policy-based governance using configuration management of Red Hat Advanced Cluster Management, can help.

To apply this approach at scale across a fleet, customers need an extensible policy framework for multicluster governance that can integrate with multiple policy engines and policy enforcement points to provide comprehensive management across the fleet of all these aspects. In this article, there is an overview of such an extensible policy framework and there are examples of how it can be used to achieve these goals.

Policy collection repository

For this article, use the upstream community, policy-collection repository to enable collaborative development of policies that cover a wide range of aspects and integrate with various policy engines and enforcement points. You can provide feedback on existing policies and also contributions of new policies from the community.

Policy management terminology

Learn more about policy management by reviewing the following overview and terminology in this section.

Policy Authoring Point (PAP)

The Policy Authoring Point (PAP) is where the policy is specified. The PAP can be a user interface or console, command line interface (CLI), or it could be a repository where policies are stored. It is best practice to use the GitOps approach so that policies are stored in GitHub and can be governed just like source code. See the blog, Contributing and deploying community policies with Red Hat Advanced Cluster Management and GitOps, for a detailed example to apply policies using GitOps.

Policy Management Point (PMP)

The Policy Management Point (PMP) is the central hub that distributes the policy to drive configuration of various aspects to the desired state, consolidates policy violations across fleet, and integrates with enterprise tools like, security operations center, incident management, and enterprise governance. It also automates remediation using automation tools such as Red Hat Ansible, provides compliance readiness posture, and renders a contextual and integrated view of compliance posture per cluster and per application for the SRE, and application developer personas.

Policy Enforcement Point (PEP)

The Policy Enforcement Point (PEP) provides technology for one or more controls related to aspects such as security, resiliency, and software engineering. It consumes policies distributed by PMP, returns results of policy evaluation in inform mode, and updates the control to the desired state in enforce mode. Optionally, you can use a PEP to invoke a Policy Decision Point (PDP) or serve as the PDP itself.

Policy Decision Point (PDP)

A Policy Decision Point (PDP) renders policy decisions by evaluating the specified policy against the current state of the control in question.

View some examples of these policy management aspects in the following list:

Extensible policy framework

Continue reading for an overview of the design of our Open Cluster Management policy framework and how it is extensible. The key characteristics of an extensible policy framework are in the following list:

  • Openness: The framework can not be opinionated about supported policy engines and policy languages. Each policy engine and language has its pros and cons. The ability to support multiple policy engines and policy languages is very important.

  • Consistency: While the framework needs to support multiple policy engines and policy languages, it is best to provide a consistent way to apply these policies and retrieve results.

  • Independence: It is very common that when comes to the integration, code changes are required and dependencies are introduced. An efficient design of an extensible policy framework should not require code change or introduce dependencies on the existing policy engines, as they should be able to run independently outside of the framework.

View the following architecture of the Open Cluster Management policy framework:

security-arch

Continue reading for a description of the high-level overall flow:

  • The policy framework distributes the policy from the hub cluster to managed clusters.
  • The policy engines and controllers that run on the managed cluster evaluates and executes the policy. As soon as a result is available, the policy engine generates Kubernetes events.
  • The policy framework monitors the events, extracts the result from the events, and sends it back to the hub cluster.
  • The hub cluster policy framework aggregates the results from the managed clusters and presents the final results for all managed clusters.

As previously described, the communication mechanism between policy framework and policy engines are through standard Kubernetes events. This mechanism helps ensure that the policy engine does not have any code dependencies on the framework and can be deployed as a standalone, or together with the framework. The policy engine works for both scenarios.

Policy CRDs are designed and implemented to achieve the goal of an extensible policy framework. Users can use the policy framework to deliver policies to multiple managed clusters by simply defining the Policy, PlacementBinding, and Placementrule custom resources.

Visit the Open Cluster Management repository, see The Policy CRDs for examples and details of the Policy, PlacementBinding, and Placementrule CRDs. You can also watch the recordings of the Open Cluster Management - Policy Framework community call.

Integration with multiple policy engines

There are several policy engines that are gaining traction for Kubernetes clusters. These are applicable for single clusters and typically register themselves as a Kubernetes webhook. Examples of policy engines are Kyverno and Gatekeeper/OPA.

Open Cluster Management extensible policy framework can efficiently integrate with these policy engines without having to write any code, but by authoring policies. This is achieved by using the configuration policy, which is one of the out-of-the-box policy engines as part of Open Cluster Management policy framework.

The configuration policy can be used to create, patch, delete, and audit any Kubernetes objects. See the configuration-policy/README.md for example policies for various scenarios. You can also learn how to use configuration policy by watching the recordings of the Open Cluster Management - Configuration policy deep dive -- part 1 and Deep Dive part 2.

Example policies for policy engines:

For more policy examples, visit the policy-collection repository to view the Community folder. For more information about Gatekeeper, visit the Open Policy Agent repository. See Kyverno for more details. See the PolicyReports README for more information about PolicyReports.

Integration with multiple Policy Enforcement Points

In this section, view the following table for examples of integration with various Red Hat and thrid-party PEPs. The PEP integrations are used to ensure that security and other capabilities they provide are in place across the fleet, configured properly, and any violations are consolidated into the hub cluster.

PEP Description Open Cluster Management policies
Red Hat Container Security Operator Detects security vulnerabilities in container images for Quay repositories. policy-imagemanifest.yaml
Red Hat Complinace Operator This operator is used by OpenShift Container Platform administrators to describe the desired compliance state of a cluster, and provides them with an overview of gaps and ways to remediate them. policy-compliance-operator-install.yaml
SysDig Secure Helps cloud teams confidently secure the build pipeline, detect and respond to runtime threats, continuously validate compliance, and perform container forensics. policy-sysdig.yaml
Falco A container native runtime security technology that enables visibility into the behavior of containers and applications. policy-falco.yaml
Synopsys Black Duck 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. policy-blackduck.yaml
Red Hat Advanced Cluster Management Configuration policy controller Enforces or informs of mismatches from any Kubernetes custom resource on your managed clusters. This ensures a desired configuration state of the cluster to conform to best practices for security, resiliency, and software engineering aspects. configuration-policy
Red Hat Advanced Cluster Management Certificate management policy controller Ensure certificates are not expiring within a given minimum time frame, and wild card certificates are not being used. policy-certificate
Red Hat Advanced Cluster Management IAM policy controller Limits the number of cluster administrator for Openshift users. policy-limitclusteradmin.yaml

Conclusion

In this blog, you have learned how an extensible policy framework can be used to provide multicluster governance for various aspects to meet enterprise standards and regulatory compliance. We invite you to participate in the Open Cluster Management community to leverage and enhance this policy framework. You can contribute policies to help us create a comprehensive library of policies for best practices that can benefit the broader ecosystem.


Categories

How-tos, Security, Red Hat Advanced Cluster Management, Multi-Cluster, Red Hat Advanced Cluster Security for Kubernetes

< Back to the blog