All Products
Search
Document Center

Container Service for Kubernetes:Use Kyverno for policy governance

Last Updated:Dec 24, 2025

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.

image

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, and generate operations. 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 NetworkPolicies or ConfigMaps, 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 mutate or generate policies.

    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.

Important

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

  1. On the Clusters page, find the cluster you want and click its name. In the left navigation pane, choose Applications > Helm.

  2. 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

ClusterPolicy

A general-purpose policy type that supports validate, mutate, and generate rules.

ValidatingPolicy (Alpha in v1.15)

Validates Kubernetes resources or workload templates. It extends the capabilities of the native ValidatingAdmissionPolicy to provide more comprehensive enterprise-grade validation.

MutatingPolicy (Alpha in v1.15)

Modifies Kubernetes resources or workload templates. It extends the capabilities of the native MutatingAdmissionPolicy for more comprehensive policy governance.

GeneratingPolicy (Alpha in v1.15)

Generates and synchronizes specified Kubernetes resources based on CEL expressions.

DeletingPolicy (Alpha in v1.15)

Cleans up specified resources at the cluster or namespace level.

ImageValidatingPolicy (Alpha in v1.15)

Verifies image signatures and attestations. Supports cosign/notary signature checks, software bill of materials (SBOM) validation, and more.

Apply in production

  • Configure a failure policy

    The failurePolicy defines 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 requests and limits for 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.