Policy and governance play a crucial role in the effective management of Kubernetes clusters, especially in large enterprise organizations. As we mentioned in our overview blog on Kubernetes governance and policy [Link to Take the Con blog], governance involves specifying policies, enforcing them, and implementing mechanisms for reporting and auditing to ensure compliance with organizational standards and external regulations.
One key aspect of governance in Kubernetes is managing Kubernetes resources, which can quickly grow from a few to hundreds or thousands in a production cluster. This presents significant challenges in terms of managing and enforcing policies across a large number of resources. Policy and governance in Kubernetes are essential for ensuring that all resources adhere to current best practices, comply with security policies, and align with company conventions.
Kubernetes governance encompasses various areas and practices, including image management, pod security, network policies, and configuration constraints. These areas are critical for maintaining the security, compliance, and operational integrity of Kubernetes clusters. For example, image management policies can enforce image scanning and restrict the use of images to those that are vetted and from specific registries, while network policies control traffic flow between pods and other network entities to enforce compliance with security and regulatory requirements.
Policy and governance in Kubernetes are not only about enforcing policies at runtime but also about restricting the way fields are configured in Kubernetes resources before they are created. This level of control ensures that only compliant Kubernetes resource specifications are allowed and committed to the cluster state. It is essential to have flexible and scalable tooling to ensure that all resources defined on a cluster comply with the organization’s defined policies.
In practical terms, Kubernetes governance and policy are often enforced by using admission controllers and interacting with API requests that flow through the Kubernetes API Server. K8s was designed to be extensible, and in this case, by validating and mutating API requests. This is explained with a diagram in our Kubernetes Governance and Policy blog, and, below, we’ve summarized some of the most popular open source policy engines, which can be used to address aspects of security, as well as compliance, and governance concerns.
Open Policy Agent (OPA) is a policy engine for cloud-native environments generally, and Gatekeeper, below, uses OPA as an admission control webhook which makes it more specific for K8s. The Open Policy Agent (OPA) decouples policies from the services it controls and can be used in any context for apps, infrastructure, and services.
Gatekeeper is an open-source implementation of OPA, and a Kubernetes admission webhook that enables cluster policy and governance. It uses the OPA constraint framework to enforce policies and ensure that only compliant resource specifications are committed to the cluster.
You can use Gatekeeper and OPA to define constraint templates that serve as policy templates, allowing for the sharing and reuse of policies across clusters. Constraint templates consist of typed parameters and target rego, which can be expressed as parameters for reuse. These templates can be used to enforce policies such as only allowing containers from trusted image registries, ensuring unique Ingress hostnames, and setting resource limits for containers.
Both OPA and Gatekeeper use the Rego language to define policies, which partly explains the next open source option on our list.
Kyverno is a policy engine designed specifically for Kubernetes that uses simple YAML configurations to define and enforce policies. As mentioned previously, Kyverno is an example of a policy engine that uses a dynamic admission controller, where it receives HTTP callbacks from the API server and applies policies to callbacks.
In the chart below, we have compared Gatekeeper and Kyverno, which are generally considered the two most popular policy and governance open-source tools.
Outside of Gatekeeper and Kyverno, there are other options you may want to consider, such as:
JsPolicy—A project open-sourced by Loft, JsPolicy will be appealing if you want to use kubectl but create validating and mutating policies in JavaScript or TypeScript, instead of YAML or Rego. The project also adds a controller policy feature for responding to K8s events, not just admission controls. As you might expect, jsPolicy also benefits from all the dev tools and frameworks the JavaScript ecosystem has for testing. There is one caveat with using jsPolicy, and it’s one to consider carefully–it’s mostly maintained by Loft alone, so an organization adopting the policy engine will need to consider the resources involved in a supporting the project going forward, which may require a greater commitment the other options.
Kubewarden—Originally developed by Rancher and a CNCF sandbox project like Kyverno, Kubewarden distinguishes itself from the others by supporting any language that can be compiled into WebAssembly. In practice, this means Go (via a special but limited compiler), Rego (using OPA or Gatekeeper), Rust, Swift (using SwiftWasm), and AssemblyScript ( a subset of TypeScript). It also uses its own CLI for managing policies: kwctl.
What open source policy engine you decide to use (or whether you opt for a proprietary solution offered by one of your providers) may likely depend on the expertise and personal preferences of your existing team and your ability to train them on new technologies.
To discuss your best options in more detail and your Kubernetes compliance needs, book a free, confidential call with 360 Cloud Platforms today!