Kyverno is a policy engine designed natively for Kubernetes that allows you to manage security, compliance, and automation policies using a Policy-as-Code approach. As an alternative to Open Policy Agent (OPA) Gatekeeper (the default policy engine in ACK), Kyverno enables you to define policies using standard YAML, eliminating the need to learn a specialized language like Rego. It also supports mutating and generating resources during the admission control process, making it ideal for scenarios that require highly customized policies, O&M automation, or multi-cluster policy governance.
How it works
Kyverno runs as a dynamic admission controller in a Kubernetes cluster. It intercepts admission webhook requests from the API server, performs validation or mutation operations, then returns a decision to either allow or deny the request.
The following figure shows how Kyverno uses admission webhooks to validate policies and mutate resources during the API server's admission phase.
Use cases
The default ACK Security Policy Management feature is built on OPA Gatekeeper. It comes with a built-in container security policy policy library for common compliance and O&M use cases, satisfying general auditing and enforcement needs. It also supports deploying multiple policy instances and integrates with Simple Log Service (SLS) for enhanced observability.
Kyverno is a Kubernetes-native policy engine. It uses standard CustomResourceDefinitions (CRDs) to define and manage policies, providing a simple and user-friendly experience. Its core advantages include:
YAML-based policies: Policies are written in standard YAML, consistent with other Kubernetes manifests. This lowers the learning curve by eliminating the need to learn a specialized language such as Rego.
Rich feature set: Kyverno natively supports
validate,mutate, andgenerateoperations. This covers a wider range of automation and Policy-as-Code use cases.Scan existing resources: In addition to enforcing policies at admission time, Kyverno can also scan, report, mutate, and generate configurations for existing resources in the cluster.
Automatic resource generation: Policies can automatically create related resources such as
NetworkPoliciesorConfigMaps, enabling automated configuration.
While Kubernetes now offers native ValidatingAdmissionPolicy and MutatingAdmissionPolicy, Kyverno provides more comprehensive and enterprise-grade policy governance capabilities.
Recommended use cases:
Custom policies: Quickly write and deploy policies for your CRDs.
Mutating and generating policies: When you need to use the
mutateorgeneratepolicies.Kyverno has comprehensive caching, external data integration, and reporting mechanisms. Its extended Common Expression Language (CEL) syntax library can meet the advanced Policy-as-Code needs of specific enterprise scenarios.
Multi-cluster policy governance: Use the Kyverno CLI, APIs, or integrations with GitOps tools such as ArgoCD to achieve unified policy distribution and management across multiple clusters.
Prerequisites
You have an ACK managed cluster or an ACK dedicated cluster running Kubernetes version 1.30 or later. Upgrade your cluster if needed.
Kyverno follows the the Kubernetes community's N-2 Version Skew Policy, officially supporting the current release and the two previous minor releases. Versions older than N-2 have not been fully tested and are not guaranteed to be compatible. For a detailed breakdown, refer to the official Kyverno compatibility matrix.
Install Kyverno
On the Clusters page, find the cluster you want and click its name. In the left navigation pane, choose .
Click Deploy, then follow the on-screen prompts to search for and select kyverno. Select the latest chart version, configure the parameters as needed (see Custom parameters), and complete the installation.
Policy types
Kyverno version 1.15 introduces several new policy types. For details, see Policy types.
Policy type | Description |
| A general-purpose policy type that supports |
| Validates Kubernetes resources or workload templates. It extends the capabilities of the native |
| Modifies Kubernetes resources or workload templates. It extends the capabilities of the native |
| Generates and synchronizes specified Kubernetes resources based on CEL expressions. |
| Cleans up specified resources at the cluster or namespace level. |
| Verifies image signatures and attestations. Supports |
Apply in production
Configure a failure policy
The
failurePolicydefines how the API server behaves when a webhook call to Kyverno fails. Configure this policy based on your specific security and O&M requirements. For configuration details, see Security vs. Operability.Fail-open: Allows API requests to proceed even if the webhook fails. This maintains cluster availability but may pose a security risk.Fail-closed: Blocks API requests if the webhook fails. This ensures security but can disrupt cluster operations.
Configure high availability and observability
High availability deployment: Run Kyverno with multiple replicas. Use a combination of pod anti-affinity and topology spread constraints to distribute the replicas across different nodes or availability zones.
Resource planning: Set clear resource
requestsandlimitsfor the Kyverno pods to ensure predictable performance.Monitoring and alerting: Enable monitoring with Managed Service for Prometheus to track key metrics, such as pod status, resource utilization, webhook latency, and error rates. Then, configure alerts for these metrics to be notified of potential issues.
For more high-availability recommendations, see High availability.