With the elimination of Pod Security Policies (PSPs) in Kubernetes v1.25, it is imperative to have insights regarding the future of Kubernetes’ policies. Kubernetes has removed PSPs and replaced them with a controller called Pod Security Admission, which uses formal controls called Pod Security Standards (PSS). However, the Pod Security Admission exists as a deficient successor with many drawbacks, such as the limitation to work only on pods, unconfigurable messages, complex access to audit logs, and the lack of a DevOps pipeline. Therefore, it’s time to search for suitable alternatives for policy management.
Currently, there are two primary choices to replace PSPs: Kyverno and Open Policy Agent (OPA) via Gatekeeper. Kyverno has moved from the CNCF sandbox to the CNCF Incubating project maturity level, while OPA is a CNCF graduate maturity level project. As full-fledged policy engines, both are equally strong contenders, but each comes with different strengths.
Accumulating all the information that exists regarding OPA/Gatekeeper and Kyverno, this article elaborates upon all the intricacies of each CNCF project in order to enable users to make an educated choice as they settle for one of the two projects.
Note: The text of the article will provide assessments regarding the facets of Kubernetes only.
What is a Kubernetes Policy?
Kubernetes emerged as a portable, extensible environment committed to organizing and orchestrating containerized applications within a cluster. As with all policies, Kubernetes policies codify a set of rules that applies intent to the Kubernetes environment.
Pod Security Policy in Kubernetes comprises a range of mechanisms responsible for validating Pod controls and attributes. However, PSP operates on Pods only, which can be a setback as production Kubernetes requires control of entities beyond Pods. Another drawback is that PSP only allows blocking and creating Pods, and there is no option provided by PSP related to the remediation of Pods.
Policy engines such as Gatekeeper and Kyverno possess more augmented, substantial, and versatile capabilities that extend beyond the control over Pods. These are well-designed policy engines that have the ability to provide more than basic validation and develop a framework dedicated to governing all kinds of controls within the Kubernetes environment.
Established through collaboration between various companies, notably Google and Microsoft, Gatekeeper is an open-source project that was subsequently donated to the CNCF. Gatekeeper is frequently addressed as “OPA/Gatekeeper” in order to recognize the association between Gatekeeper and Open Policy Agent that was developed in its third iteration. The iteration offers structures to thoroughly support Kubernetes-specific executions and implementations. Functioning as an extensible, parameterized policy library, Gatekeeper provides permission to request validation and mutation.
The utilization of Rego, a specialized programming language, marks a distinctive characteristic of Open Policy Agent. Those working with OPA must learn or know Rego to implement all requisite configurations for logic and policy decision-making. Furthermore, OPA is structured to execute logic at a high level and, therefore, is applicable to heterogeneous and diversified software rather than to Kubernetes exclusively.
Similar to its competitor, Kyverno also functions as an open-source policy engine project donated to CNCF after being created by the founders of Nirmata. Kyverno also possesses the capabilities to validate and mutate with the addition of Kubernetes resource generation. However, unlike Gatekeeper, Kyverno was developed and refined exclusively for Kubernetes application. Kyverno illustrates its prominence through its generation ability and architecture, and unlike other policy managers, Kyverno does not use a unique programming language, making it easier to use.
Let’s take a look at both policy engines’ capabilities, including technical characteristics, ecosystem, and other miscellaneous traits that reflect the cognitive features of each project.
* Beta status
** Not available with all CRDs
*** Separate CLI
|Image Verification||No (via extensions)||Yes|
|Image Registry lookups||No (via extensions)||Yes|
|Policy as native resources||Yes||Yes|
|OpenAPI validation schema (kubectl explain)||No**||Yes|
|API object lookup||Yes||Yes|
|CLI with test ability||Yes***||Yes|
|Policy audit ability||Yes||Yes|
|CNCF status||Graduated (OPA)||Incubation|
|GitHub status (stars, forks, releases, commits)||2700, 582, 63, 1040||2900, 400, 132, 4605|
|Downloads||100 million +||300 million|
|Policy sample library||Yes||Yes|
|Use outside Kubernetes||Yes||No|
|Birth||July 2017||May 2019|
While the tables above focus largely on the features that these policy engines have to offer, further elaboration in regards to the merits and demerits of Gatekeeper and Kyverno is mentioned below. It should be noted that the lists illustrate the essence of broader topics that we believe are key determinants of each project.
- Older than Kyverno
- Multiple replicas for scaling and availability are supported
- Holds the ability to express sophisticated and intricate policies
- Generation of technical debt and consumption of time and energy because of the unique programming language required to navigate within the engine
- Complicated and protracted policies often require various documents for execution
- Functionality limited to validation use cases
- Incipient mutation ability
- Does not require knowledge of a specialized programming language
- Well-developed mutation abilities
- Kubernetes-style framework for policy expression
- Greater flexibility and simplicity with a minimum generation of technical debt
- Supports numerous replicas for availability and scale
- Unmatched generation and synchronizing ability
- Not applicable outside Kubernetes
- Newer than OPA but still has a fast-growing community
As a declarative system, Kubernetes has the capacity to hold on to the user’s desired controls. It also dispenses many controllers that extend their functions to reconcile and orient the observed state with the user’s desired state. As a cloud-native platform, Kubernetes accomplishes this by giving the responsibility for the logic to the platform rather than to the user. Each resource type has an internal logic that provides the information needed to enhance its condition.
The fault lines within Gatekeeper become apparent because of the purpose-built programming language required to frame the above-mentioned logic. The fundamental weakness of Gatekeeper is its dependence on the Rego programming language, which is only compatible with OPA, and OPA is a general policy engine. Therefore, only through Gatekeeper is its ability harnessed by adapting it into a Kubernetes form factor. Once attuned effectively, the policy that requires alignment and reconciliation is fed the logic needed through Rego.
Because of this, added technical debt is inevitable with Gatekeeper. The utilization of external DSL to manage policies within Kubernetes requires extensive time and effort, making the overall process complex and tedious. However, as a compromise, the substantial benefit it offers is that it creates the opportunity for very strong policies.
Kyverno, on the other hand, is seen as a necessary reaction to Gatekeeper’s sophisticated technical requirements. Because of its declarative policy expression and Kubernetes-specific design, it provides a structure similar to Kubernetes in terms of object description and reconciliation. Here, the logic for decision-making becomes a part of the domain tool rather than the responsibility of the user. With Kyverno, the ramifications of policy elaboration are thoroughly simplified, making it easier to construct policies.
With its mutation and generation capabilities, coupled with the ability to do API lookups, Kyverno developed exceptionally into a full-fledged automation tool. Additionally, Kyverno also has the power to eliminate other tools that might be used haphazardly throughout the cluster and/or institution.
Functioning as a straightforward automation tool, coupled with various other tools, Kyverno offers a valuable platform to both new and experienced operators, thereby increasing its value as a policy engine.
The Gatekeeper and Kyverno projects are both powerful and efficient policy engines, each with its own advantages and disadvantages. Regardless, both hold substantial merit over PSP/PSA. As general advice, all operational users should plan on utilizing a policy engine to secure their clusters and streamline Kubernetes management. In the end, users should evaluate and make the most educated decision given their use cases and constraints.