Applying an Extensible Policy Framework for Multicluster Governance

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:

• Red Hat Advanced Cluster Management for Kubernetes and the associated Open Cluster Management upstream community project serve as PAP and PMP, and also has some built-in PEPs such as Gatekeeper/OPA, Kubernetes configuration, Certificate, and IAM policy controllers.

  Red Hat Advanced Cluster Management and Open Cluster Management integrate with Red Hat and third-party PEPs such as the Red Hat OpenShift Compliance Operator, Red Hat Container Security Operator, SysDig Falco Operator, Synopsys Black Duck, etc.

• Policy engines such as Gatekeeper and Kyverno act as PDPs.

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:

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:

• Gatekeeper integration

  • Install and configure Gatekeeper
  • Create Gatekeeper policy
  • Report Gatekeeper violations for audit scenario
  • Report Gatekeeper violations for admission scenario

• Kyverno integration

  • Create Kyverno policy
  • Report Kyverno violations (PolicyReports)

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.

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.