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 – Kyverno vs OPA/Gatekeeper.

Note: The text of the article will provide assessments regarding the facets of Kubernetes only.

Introduction

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.

Gatekeeper Introduction

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.

Kyverno Introduction

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.

Comparison of Kyverno and Gatekeeper

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.

Note:
* Beta status
** Not available with all CRDs
*** Separate CLI

Technical Characteristics

Features/Capabilities	Gatekeeper	Kyverno
Validation	Yes	Yes
Mutation	Yes*	Yes
Generation	No	Yes
Image Verification	No (via extensions)	Yes
Image Registry lookups	No (via extensions)	Yes
Extensions	Yes	No
Policy as native resources	Yes	Yes
Metrics exposed	Yes	Yes
OpenAPI validation schema (kubectl explain)	No**	Yes
High Availability	Yes	Yes
API object lookup	Yes	Yes
CLI with test ability	Yes***	Yes
Policy audit ability	Yes	Yes
Self-service reports	No	Yes

 Community Characteristics

Community/Ecosystem	Gatekeeper	Kyverno
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

 Miscellaneous Characteristics

Meta/Misc	Gatekeeper	Kyverno
Programming	Yes	No
Use outside Kubernetes	Yes	No
Birth	July 2017	May 2019
Origins	Styra (OPA)	Nirmata

Analysis

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. 

Gatekeeper Advantages

• Older than Kyverno
• Multiple replicas for scaling and availability are supported
• Holds the ability to express sophisticated and intricate policies

Gatekeeper Disadvantages

• 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

Kyverno Advantages

• 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

Kyverno Disadvantages

• Not applicable outside Kubernetes
• Newer than OPA but still has a fast-growing community

Exploring Further

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.

Conclusion

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. When it comes to Kyverno vs OPA, readers here know where our alliances are but we do know that differing DevOps teams will have varying needs.

Readers can learn more about Kyverno from Nirmata by visiting this page. Please reach-out to our team with any questions you may have after reading this post. You can get started with a free trial of Kyverno on this page.