Kyverno: Policy as Code for Automated Compliance Checks

TL;DR

• Kyverno is a Kubernetes-native policy engine that allows you to define security and operational policies directly as YAML and enforce them automatically as an admission controller within the cluster.
• With clearly structured guardrails for security (e.g., container isolation, trusted registries), reliability (e.g., resource management), and operation (e.g., storage, load balancer, and backup rules), compliance becomes a repeatable, verifiable process.
• Regulatory requirements from GDPR Art. 32 (applicable since 25.05.2018), the NIS-2 directive (with implementation deadline for EU member states by 17.10.2024), and the BSI IT-Grundschutz can be systematically mapped in your Kubernetes cluster using policy as code.
• In practice, this means deployments are checked against policies before being applied; faulty configurations are rejected with clear technical guidance before they become a risk in production.
• ayedo uses Kyverno as a central policy-as-code tool, providing predefined guardrails and reporting functions, and supports you in establishing Kyverno policies as a fixed part of your delivery and compliance strategy.

Kyverno Overview: Policy as Code, Where It Belongs

Kyverno is a policy engine specifically developed for Kubernetes. Unlike generic policy frameworks, Kyverno fully relies on Kubernetes objects and YAML. This fits well in a world where infrastructure, applications, and security configurations are already described as code.

Instead of inventing a new policy language, Kyverno uses familiar concepts:

• Policies are defined as Kubernetes resources.
• The syntax is YAML-based and aligns with the fields of the Kubernetes objects you are already deploying.
• Kyverno operates as an admission controller: Every change to resources is checked before being stored in the API server—and blocked or modified if necessary.

The result: Policies become first-class citizens in your cluster, versionable in Git, secured through reviews, and automatically effective.

Policy Types in Kyverno

Kyverno supports three central policy functions that can be combined:

• Validation: Rules check incoming resources (e.g., deployments, pods, namespaces). If a policy is violated, Kyverno can reject the change in enforce mode or just report it in audit mode.
• Mutation: Rules automatically add or correct configurations—such as default labels or default security settings.
• Generation: Rules ensure that certain objects are automatically created when another trigger occurs (e.g., automatic NetworkPolicy when a namespace is created).

Particularly important from a compliance perspective are the policy mode and reporting:

• In enforce mode, non-compliant changes are blocked.
• In audit mode, violations are logged but not prevented—ideal for introducing new rules with low risk.
• Policy reports provide an overview of which resources violate which policies—forming the basis for structured improvements.

This combination makes Kyverno a practical enabler for automated compliance: Policies are defined once and then continuously run in the background.

Guardrails Categories: Security, Reliability, Operation

To effectively anchor Kyverno in a company, it has proven useful to structure policies as guardrails—guidelines that enforce secure and robust configurations without unnecessarily restricting the autonomy of development teams.

Typically, guardrails can be categorized into three areas: Security, Reliability, and Operation.

Security Guardrails: Container Control and Trusted Registries

Security guardrails address direct security risks in workloads and infrastructure. Typical rules established in many organizations include:

Prohibition of Privileged Containers and Root Users

Many container images are built to run processes as root by default. This significantly increases the exploitability of vulnerabilities. A central guardrail ensures that:

• Containers do not run privileged,
• No root user is used,
• Security contexts are explicitly set.

Kyverno checks the relevant fields of the pod and container specification. If a deployment attempts to start a root container, the request is rejected or—at least in audit mode—logged with a clear note.

This type of guardrail directly supports control requirements like ISO 27001 and BSI APP.4.4 and helps implement access restrictions at the operating system level.

No “latest” Tags and Controlled Versions

Another classic security and compliance issue are unversioned or mutable image tags like “latest,” “dev,” or “prod.” They complicate:

• Traceability: Which version is actually running?
• Reproducibility: Can an incident be accurately replicated?
• Rollbacks: Can you specifically revert to the previous, known version?

With a Kyverno guardrail, images without explicit, stable tags can be easily rejected. This ensures that only clearly identifiable versions make it to production. This practice supports change management and traceability requirements—such as within the framework of ISO 27001 and indirectly also Art. 32 GDPR.

Trusted Container Registries

A third security guardrail focuses on the origin of images. In the simplest case, only images from a handful of trusted registries are allowed:

• The company’s own registry,
• A centrally managed scan and signature hub,
• Possibly defined partner registries.

Kyverno validates the image field of the container definition. Images from unknown sources are rejected. Combined with proper vulnerability management in the registry, this significantly increases the security level in the cluster.

Reliability Guardrails: Resource Management and Resilience

Reliability guardrails target stability and operational readiness rather than attacks.

Mandatory Resource Requests

Without defined CPU and memory requests, you risk:

• Overbooking of nodes,
• Uneven load distribution,
• Unexpected performance drops or out-of-memory kills.

A guardrail that enforces minimum resource requests (and ideally limits) for all containers is central here. Kyverno can reject deployments that have no requests set, laying the foundation for predictable capacity planning—a direct topic in the context of ISO 27001 (capacity planning) and in terms of “resilience” in Art. 32 GDPR.

Minimum Number of Replicas and PodDisruptionBudgets

For critical services in production, “single replica” is practically an anti-pattern. Kyverno can ensure that:

• Deployments in production namespaces have a minimum number of replicas,
• PodDisruptionBudgets exist or are at least recommended for highly available deployments.

Such rules help technically secure availability requirements from regulations and SLAs, rather than just describing them on paper.

Operational Guardrails: Storage, LoadBalancer & Co.

Operational guardrails address issues that can quickly become stumbling blocks in audits, even though they are rarely the daily focus of development.

Typical examples:

• Storage Usage: Specification of which StorageClasses are allowed in which environments; mandatory annotations for the backup relevance of PersistentVolumeClaims. This supports backup and disaster recovery requirements.
• LoadBalancer Use: Restrictions for external load balancers to prevent uncontrolled exposure of services to the internet; central control via ingress controllers instead of direct service exposure.
• Secrets Management: Ensuring that applications no longer directly include secrets in the manifest, but rather use a solution like the External Secrets Operator (ESO). Kyverno can check whether sensitive configurations are only referenced from trusted sources.

These guardrails often remain “invisible” until an audit or incident brings them into the spotlight. With policy as code, they become reproducible, documented, and traceable.

Regulatory Context: GDPR Art. 32, NIS-2, and BSI IT-Grundschutz

Regulation is now a central framework for technical decisions—especially in critical infrastructures, financial services, healthcare, and the public sector. Kyverno is not a “compliance tool” in the strict sense, but a very effective tool for systematically implementing technical requirements from standards and laws.

GDPR Art. 32: Security of Processing

The General Data Protection Regulation has been applicable in all EU member states since 25.05.2018. Art. 32 requires “appropriate technical and organizational measures” to ensure an adequate level of protection—particularly:

• Confidentiality, integrity, availability, and resilience of systems,
• The ability to regularly review, assess, and evaluate security.

Policy as code with Kyverno supports these requirements in several dimensions:

• Technical measures (e.g., network segmentation, resource isolation) are implemented as repeatable, versioned policies.
• Effectiveness can be objectively evaluated based on policy reports and block statistics.
• Regular reviews and adjustments of policies become a regular part of the change management process.

Instead of managing security requirements in Word documents, they become living, verifiable parts of your platform.

NIS-2: Security in Development and Operation of Critical Services

The NIS-2 directive of the EU came into force on 16.01.2023; member states must implement it into national law by 17.10.2024. It tightens the requirements for companies in critical sectors—among other things regarding:

• Secure design and development of systems,
• Vulnerability handling and patch management,
• Operational security and incident prevention.

For organizations falling under NIS-2, this means they must demonstrate that security not only exists on paper but is embedded in development and deployment processes.

Kyverno-based guardrails are a strong component for this:

• They embed security requirements directly into the Kubernetes platform.
• They ensure that insecure configurations do not go unnoticed into critical environments.
• They provide measurable metrics on rule violations, blockages, and policy coverage.

In combination with overarching governance structures—see our compliance area—a robust evidence base is created for regulatory authorities.

BSI IT-Grundschutz: Admission Controller and Access Protection

The BSI IT-Grundschutz formulates specific recommendations for container and orchestration environments, including:

• Access protection to control plane functions,
• Consistent use of admission controllers,
• Assignment of resources via namespaces and policies.

Kyverno addresses exactly this: It extends the native admission controller mechanism of Kubernetes with a flexible policy layer. This allows BSI requirements such as:

• Segmented namespaces,
• Mandatory NetworkPolicies,
• Defined security contexts and roles.