Container Service for Kubernetes:Use Kyverno as a policy governance engine

Why use Kyverno

In ACK, the Security policy management feature provides policy governance based on Open Policy Agent (OPA) Gatekeeper by default. The feature includes a built-in container security policy rule library that covers different security compliance and operations scenarios. This rule library meets common audit and interception requirements. The feature also supports the deployment of multiple policy instances and integrates with Simple Log Service (SLS) to improve the observability of policy governance.

Kyverno is a policy engine designed for Kubernetes. It uses standard CustomResourceDefinitions (CRDs) to define and manage policies, which provides a simpler and easier-to-use experience. Its core advantages include:

• YAML-based definitions: Policies are written in standard YAML, consistent with the style of Kubernetes manifests. You do not need to learn a dedicated policy language such as Rego, which lowers the barrier to use.

• Broad feature support: Kyverno natively supports Validate, Mutate, and Generate operations, which cover a wider range of automation and Policy-as-Code scenarios.

• Coverage of existing resources: Kyverno takes effect when resources are admitted. It can also scan existing resources in a cluster, report on them, and apply Mutate and Generate operations to them.

• Automatic generation of related resources: Kyverno can automatically create related resources such as NetworkPolicy and ConfigMap based on policies to automate configuration.

Scenarios

Compared with the native Kubernetes ValidatingAdmissionPolicy and MutatingAdmissionPolicy, Kyverno provides more comprehensive enterprise-grade policy governance capabilities. For the capabilities that each Kyverno version adds, see the release announcements for Kyverno 1.14 and Kyverno 1.15. Kyverno is recommended in the following scenarios:

• Custom policies: You need to write and deploy policies for CRDs quickly.

• Mutate and Generate policies: You need policies that mutate resources at admission or generate related resources automatically.

  Kyverno also provides mature caching, external data call, and reporting mechanisms, and extends the Common Expression Language (CEL) libraries to meet Policy-as-Code extension requirements in specific enterprise scenarios.

• Multi-cluster policy governance: You want to distribute and manage policies across multiple clusters through the command-line interface (CLI), API, or integration with GitOps tools such as Argo CD.

How it works

Kyverno runs in a Kubernetes cluster as a dynamic admission controller. It intercepts webhook admission requests from the API server, applies Validate or Mutate operations, and returns the admission decision.

The following figure shows how an admission request flows between the API server and Kyverno during policy evaluation.

Prerequisites

• An ACK managed cluster that runs Kubernetes 1.30 or later, or an existing ACK dedicated cluster that runs Kubernetes 1.30 or later. New creation of ACK dedicated clusters is no longer available. If the cluster runs an earlier Kubernetes version, upgrade it first. For instructions, see Upgrade a cluster.

  Kyverno follows the N-2 version support policy of the Kubernetes community and maintains the current version and the two preceding minor versions. Earlier versions are not fully tested, and compatibility is not guaranteed. For version compatibility information, see the Kyverno compatibility matrix.

Install the Kyverno add-on

1. On the Clusters page, click the name of the cluster that you want to manage. Then, in the left-side navigation pane, choose Applications > Helm.

2. Click Create.

3. Follow the on-screen instructions to search for and select kyverno.

4. Set Chart Version to the latest version and configure the corresponding parameters. For more information, see Customization. Before you configure the parameters for a production cluster, review the recommendations in the Use in production environments section of this topic.

   The Kyverno add-on is then installed in the cluster.

Policy types

Kyverno adds multiple policy types in version 1.15. The following table describes the policy types that Kyverno provides. For more information, see Policy types.

Use in production environments

• Configure a failure policy that matches your security and operability requirements. failurePolicy defines the behavior of the API server when a webhook call fails. Two behaviors are possible:

  • Fail-open: The API server allows the API request to proceed, which may introduce security risks.

  • Fail-closed: The API server blocks the API request, which may interrupt cluster operations.

    For more information about this configuration, see Security vs. Operability in the Kyverno installation documentation.

• Configure high availability and observability for the Kyverno add-on:

  • High availability: Run Kyverno with multiple replicas. Use pod anti-affinity together with topology spread constraints to distribute the replicas across different nodes or zones. For more high availability recommendations, see High availability.

  • Resource planning: Configure explicit resource requests and limits for Kyverno pods.

  • Monitoring and alerting: Enable Managed Service for Prometheus to monitor key metrics such as pod status, resource utilization, webhook latency, and error rate, and configure alerts.