Level Up Your Kubernetes Security and Automation with Policy as Code
Updated Nirmata Team
Policy as code for Kubernetes security means writing the rules your clusters must follow, such as RBAC, network policies, resource quotas and image signature checks, as code that is reviewed, versioned and enforced automatically. Kubernetes applies these rules at admission, through webhooks or built-in CEL policies, and engines like Kyverno extend them with mutation, generation and background scanning.
Kubernetes is powerful and flexible, but that power comes with the responsibility of keeping your clusters secure, compliant and well managed. Policy as Code (PaC) treats infrastructure policies as code, which makes them easier to maintain, more efficient to run and open to inspection. If you are new to the idea, start with what policy-as-code is and why teams adopt it.
The topic took center stage at the most recent KubeCon London, where the session on “A Practical Guide to Kubernetes Policy as Code” drew a standing-room-only crowd. Interest in Kubernetes policy management is clearly growing as more organizations run Kubernetes at scale.
As Andy Suderman, CTO of Fairwinds and co-chair of the Policy Working Group, aptly puts it, “policy underpins just about everything that you might care about in your Kubernetes cluster.” From Role-Based Access Control (RBAC) to network policies and resource quotas, policy sits underneath your Kubernetes operations. Jimmy Ray, another member of the Policy Working Group, defines Policy as Code as “the use of code artifacts to manage and apply rules and conditions,” a simple idea with large consequences.
The advantages mirror those of Infrastructure as Code: better maintainability, efficiency through automation, collective inspection through code reviews, and clear visibility into how policies behave in your system. Kubernetes itself offers several built-in mechanisms to enforce these policies.
How has Kubernetes policy enforcement evolved?
Joe Betz, Staff Engineer at Google and SIG API Machinery lead, took the audience through the evolution of policy enforcement in Kubernetes. The introduction of admission webhooks in Kubernetes v1.8 was a turning point. It gave Kubernetes a foundational extension point for intercepting write requests to the control plane. Webhooks are powerful, but they made development, maintenance, upgrades and availability harder, so they became critical components to manage carefully.
“You can intercept all write requests coming into the control plane and that gives you the ability to control what is happening in your cluster,” Betz explained.
Many of these webhooks, though, were doing fairly simple validation. That led to embedding logic directly in the Kubernetes API server using the Common Expression Language (CEL), which offers YAML embeddability, a familiar C-style syntax and low execution overhead.
“The vast majority of webhooks were doing really simple stuff,” Betz noted. “If it’s really simple logic, why not just put it straight into the Kubernetes API server in the first place?” Today, CEL is widely used for CRD validation and forms the backbone of Kubernetes’ new policy primitives: Validating Admission Policy (VAP) and Mutating Admission Policy (MAP). VAP validates incoming requests, while MAP, currently in alpha, enables object mutation through patches.
Where does OPA Gatekeeper fit?
Rita Zhang, Principal Engineer at Microsoft and chair of SIG Auth, introduced OPA Gatekeeper, a CNCF-graduated project that brings enterprise-grade policy enforcement to Kubernetes. Gatekeeper is a dynamic, flexible admission and mutation webhook, designed to let users write policies once and run them across multiple environments.
“We want to make sure you can write the language of your choice,” said Zhang, highlighting Gatekeeper’s support for both Rego and CEL.
Gatekeeper also lets policy authors and deployers work independently through Constraint Templates and Constraints. Its features include audit of existing resources, a CLI tool (Gator) for CI/CD pipelines, Prometheus metrics, integration with external data sources and Pub/Sub notifications for policy violations. Zhang stressed that Gatekeeper isn’t competing with Kubernetes’ built-in policy mechanisms. “We do not want to compete with VAP—we love VAP,” she said. Gatekeeper aims to complement and extend the built-in tools.
How does Kyverno extend Kubernetes policy?
Jim Bugwadia, co-chair of the Policy Working Group and a maintainer of Kyverno, presented a different vision. Unlike other tools that focus mainly on validation, Kyverno was designed from the start by Nirmata to cover a broader range of policy use cases, including mutation, generation, cleanup, and image validation.
“Policy as Code is not just about validation or enforcing security,” said Bugwadia. “It’s about automation as well. It’s about reducing the overload of additional controllers.”
Kyverno’s goal is to simplify policy management for Kubernetes administrators without making them learn a new policy language. It now supports generating both VAP and MAP policies from Kyverno definitions, using CEL where applicable. Users get the performance and stability of native Kubernetes features, and Kyverno’s toolset covers what those features don’t.
What sets Kyverno apart?
| Capability | What it does |
|---|---|
| Extended policy capabilities | Beyond validation, Kyverno includes resource mutation, generation, cleanup, and image validation. |
| Flexible evaluation modes | Policies can target Kubernetes resources or arbitrary JSON/YAML payloads. |
| Webhook configuration options | Offers fine-tuned control over webhook behavior. |
| Policy autogeneration | Automatically generates policies for Kubernetes workloads and admission policies. |
| Enhanced CEL integration | Includes advanced CEL features like image registry lookups. |
| Background scanning | Applies policies to existing resources for retroactive compliance. |
| Fine-grained exceptions | Supports per-image policy exceptions. |
| Standardized reporting | Adheres to Policy Working Group formats for audit and reporting. |
| Image signature verification | Integrates with Notary and Cosign to validate image signatures and attestations. |
| Cross-platform potential | Kyverno policies can be adapted for non-Kubernetes use cases with minimal changes. |
Kyverno from Nirmata helps platform engineers, security teams, operators and DevOps teams work together using familiar Kubernetes-native tools and workflows. For a rollout plan, see the Kyverno playbook.
What did the panel recommend?
Andy Suderman closed the session by reinforcing the Kubernetes community’s commitment to Policy as Code. He encouraged attendees to invest in learning CEL, which is fast becoming a core technology across many Kubernetes features. Built-in policies are a good starting point, but extensions like Kyverno and Gatekeeper remain necessary for complex scenarios.
“Everybody wants to use mutation for everything. Try to keep it to a minimum—it’s expensive and it can be risky,” Suderman advised.
The discussion ended with CI/CD integration, and how GitOps platforms like Argo CD and Flux now support server-side apply so they coexist better with mutation policies.
The key takeaway: Kubernetes now provides a solid foundation for Policy as Code, but knowing when and how to extend it, through tools like Kyverno, is essential at scale.
Where to go next
The Nirmata team maintains Kyverno, a policy engine built for Kubernetes, and we help platform teams succeed with secure, automated and scalable policy management.
Reach out to us to learn more, get hands-on guidance, or see how Policy as Code fits your Kubernetes strategy. Get the data sheet on Nirmata Control Hub, which covers automating Kubernetes security and operations through Policy as Code. For a side-by-side view of the two main engines, read Kyverno versus OPA/Gatekeeper. You can also request a free demo.
Frequently asked questions
What is the difference between ValidatingAdmissionPolicy and MutatingAdmissionPolicy?
Both are built into the Kubernetes API server and use CEL expressions, so no webhook is needed. A ValidatingAdmissionPolicy accepts or rejects a request; it has been generally available since Kubernetes v1.30. A MutatingAdmissionPolicy changes the incoming object by applying patches before it is stored. It arrived later than validation, so check its feature stage for your Kubernetes version before relying on it.
Do I still need Kyverno or Gatekeeper if Kubernetes has built-in admission policies?
For simple validation, built-in policies may be enough. Extensions earn their place when you need more: generating resources such as default network policies, cleaning up resources, verifying image signatures, scanning existing resources in the background, or producing policy reports. Kyverno can also generate ValidatingAdmissionPolicy and MutatingAdmissionPolicy resources from its own policies, so the two approaches work together.
How does Kyverno verify container image signatures?
Kyverno image verification rules check that an image was signed by a trusted key or identity before a pod using it is admitted. Kyverno integrates with Sigstore Cosign and Notary, and it can also check attestations attached to an image, such as a software bill of materials or vulnerability scan results. Unsigned or untrusted images can be blocked in Enforce mode or reported in Audit mode.
How do policies apply to resources that already exist in a cluster?
Admission control only sees new requests, so Kyverno also runs background scans that evaluate existing resources against its policies. Results are written as PolicyReport resources, a format defined by the Kubernetes Policy Working Group, which other tools can read. This lets teams roll out a new policy in Audit mode, review the violations it finds, and fix them before switching to Enforce.