Kyverno

https://kyverno.io/docs/security/

Kyverno serves an admission controller and is a critical component of the Kubernetes control plane. It is important to properly secure and monitor Kyverno. This section provides guidance on securing Kyverno and the security processes for the Kyverno project.

Disclosure Process

Security vulnerabilities are best handled swiftly and discretely with the goal of minimizing the total time users remain vulnerable to exploits.

If you find or suspect a vulnerability, please email the security group at [e-mail] with the following information:

• description of the problem

• precise and detailed steps (include screenshots) that created the problem

• the affected version(s)

• any known mitigations

The Kyverno security response team will send an initial acknowledgement of the disclosure in 3-5 working days. Once the vulnerability and mitigation are confirmed, the team will plan to release any necessary changes based on the severity and complexity. Additional details on the security policy and processes are available in the Kyverno git repo.

Contact Us

To communicate with the Kyverno team, for any questions or discussions, use Slack or GitHub.

Issues

All security related issues are labeled as security and can be viewed here.

Release Artifacts

The Kyverno container images are available here.

With each release, the following artifacts are uploaded:

• checksums.txt

• install.yaml

• kyverno-cli-<version_number>.tar.gz

• kyverno-cli_v<version_number>_darwin_arm64.tar.gz

• kyverno-cli_v<version_number>_darwin_x86_64.tar.gz

• kyverno-cli_v<version_number>_linux_arm64.tar.gz

• kyverno-cli_v<version_number>_linux_s390x.tar.gz

• kyverno-cli_v<version_number>_linux_x86_64.tar.gz

• kyverno-cli_v<version_number>_windows_arm64.zip

• kyverno-cli_v<version_number>_windows_x86_64.zip

• Source code (zip)

• Source code (tar.gz)

Verifying Kyverno Container Images

Kyverno container images are signed using Cosign and the keyless signing feature. The signatures are stored in a separate repository from the container image they reference located at ghcr.io/kyverno/signatures. To verify the container image using Cosign v1.x, follow the steps below.

1. Install Cosign
2. Configure the Kyverno signature repository:

export COSIGN_REPOSITORY=ghcr.io/kyverno/signatures

bash

1. Verify the image:

COSIGN_EXPERIMENTAL=1 cosign verify ghcr.io/kyverno/kyverno:<release_tag> | jq

bash

For Cosign v2.x, use the following command instead.

COSIGN_REPOSITORY=ghcr.io/kyverno/signatures cosign verify ghcr.io/kyverno/kyverno:<release_tag> \
  --certificate-identity-regexp="https://github.com/kyverno/kyverno/.github/workflows/release.yaml@refs/tags/*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" | jq

If the container image was properly signed, the output should be similar to:

Note that the important fields to verify in the output are optional.Issuer and optional.Subject. If Issuer and Subject do not match the values shown above, the image is not genuine.

All Kyverno images can be verified.

Verifying Provenance

Kyverno creates and attests to the provenance of its builds using the SLSA standard and meets the SLSA Level 3 specification. The attested provenance may be verified using the cosign tool.

For v1.x of Cosign, use the following command.

For v2.x of Cosign, use the following command.

The output will look something similar to the below.

Fetching the SBOM for Kyverno

An SBOM (Software Bill of Materials) in CycloneDX JSON format is published for each Kyverno release, including pre-releases. Like signatures, SBOMs are stored in a separate repository at ghcr.io/kyverno/sbom. To download and verify the SBOM for a specific version, install Cosign and run:

To save the SBOM to a file, run the following command:

Security Scorecard

Kyverno uses Scorecards by OSSF to maintain repository-wide security standards. The current OSSF/scorecard score for Kyverno can be found in this tracker issue. The Kyverno team is committed to achieving and maintaining a high score. Contributions are welcome.

Vulnerability Scan Reports

The Kyverno Helm Chart is available via the Artifact Hub page along with an auto-generated Security Report generated by Artifact Hub for all the releases.

Security Best Practices

The following sections discuss related best practices for Kyverno:

Pod security

Kyverno Pods are configured to follow security best practices and conform to the Pod Security Standards restricted profile:

• runAsNonRoot is set to true

• privileged is set to false

• allowPrivilegeEscalation is set to false

• readOnlyRootFilesystem is set to true

• all capabilities are dropped

• limits and quotas are configured

• liveness and readiness probes are configured

RBAC

The Kyverno RBAC configurations are described in the installation section.

Use the following command to view all Kyverno roles:

Networking

Kyverno network traffic is encrypted and should be restricted using NetworkPolicies or similar constructs.

By default, a Kyverno installation does not configure NetworkPolicies (see this issue). The Kyverno Helm chart has a networkPolicy.enabled option to enable a NetworkPolicy.

Kyverno requires the following network communications to be allowed:

• ingress traffic to port 9443 from the API server

• ingress traffic to port 9443 from the host for health checks

• ingress traffic to port 8000 if metrics are collected by Prometheus or other metrics collectors

• egress traffic to the API server if the API Call feature is used
• egress (HTTPS) traffic to OCI registries if image verification policy rules are configured or if image registry context variables are used
• egress (HTTP or HTTPS) traffic to external services if the external service call feature is used

Webhooks

Use the following command to view all Kyverno Roles:

Kyverno creates the following mutating webhook configurations:

• kyverno-policy-mutating-webhook-cfg: handles policy changes to index and cache policy sets.

• kyverno-resource-mutating-webhook-cfg: handles resource admission requests to apply matching Kyverno mutate policy rules.

• kyverno-verify-mutating-webhook-cfg: periodically tests Kyverno webhook configurations

Kyverno creates the following validating webhook configurations:

• kyverno-policy-validating-webhook-cfg: validates Kyverno policies with checks that cannot be performed via schema validation

• kyverno-resource-validating-webhook-cfg: handles resource resource admission requests to apply matching Kyverno validate policy rules.

• kyverno-cleanup-validating-webhook-cfg: handles cleanup policies

• kyverno-exception-validating-webhook-cfg: handles policy exceptions

Webhook Failure Mode

Kyverno policies are configured to fail-closed by default. This setting can be tuned on a per policy basis. Kyverno uses the configured policy set to automatically configure webhooks.

Webhook authentication and encryption

By default, Kyverno automatically generates and manage TLS certificates used for authentication with the API server and encryption of network traffic. To use a custom CA, please refer to the details in the installation section.

Recommended policies

The Kyverno community manages a set of sample policies.

At a minimum, the Pod Security Standards and best practices policy sets are recommended for use.

Securing policies

Kyverno policies can be used to mutate and generate namespaced and cluster-wide resources. Hence, policies should be treated as critical resources and access to policies should be protected using RBAC.

Threat Model

The Kubernetes SIG Security team has defined an Admission Control Threat Model. It is highly recommended that Kyverno administrators read and understand the threat model, and use it as a starting point to create their own threat model.

The sections below list each threat, mitigation, and provide Kyverno specific details.

Threat ID 1 - Attacker floods webhook with traffic preventing its operations

Threat Model Link

Mitigation:

• Mitigation ID 2 - Webhook fails closed

  Kyverno policies are configured fail-closed by default. This setting can be tuned on a per policy basis. Kyverno uses the configured policy set to automatically configure webhooks.

Threat ID 2 - Attacker passes workloads which require complex processing causing timeouts

Threat Model Link

Mitigations:

• Mitigation ID 2 - Webhook fails closed

  Kyverno policies are configured fail-closed by default. This setting can be tuned on a per policy basis. Kyverno uses the configured policy set to automatically configure webhooks.
• Mitigation ID 3 - Webhook authenticates callers

  By default, Kyverno generates a CA and X.509 certificates for the webhook registration. A custom CA and certificates can be used as discussed in the configuration guide. Currently, Kyverno does not authenticate the API server. A network policy can be used to restrict traffic to the Kyverno webhook port.

Threat ID 3 - Attacker exploits misconfiguration of webhook to bypass

Threat Model Link

Mitigation:

• Mitigation ID 8 - Regular reviews of webhook configuration catch issues

  Kyverno automatically generates webhook configurations based on the configured policy set. This ensures that webhooks are always updates and minimally configured.

Threat ID 4 - Attacker has rights to delete or modify the Kubernetes webhook object

Threat Model Link

Mitigation:

• Mitigation ID 1 - RBAC rights are strictly controlled

  Kyverno RBAC configurations are described in the installation section. The kyverno:admission-controller role is used by Kyverno to configure webhooks. It is important to limit Kyverno to the required permissions and audit changes in the RBAC roles and role bindings.

Threat ID 5 - Attacker gets access to valid credentials for the webhook

Threat Model Link

Mitigation:

• Mitigation ID 2 - Webhook fails closed

  Kyverno policies are configured fail-closed by default. This setting can be tuned on a per policy basis. Kyverno uses the configured policy set to automatically configure webhooks.

Threat ID 6 - Attacker gains access to a cluster admin credential

Threat Model Link

Mitigation

N/A

Threat ID 7 - Attacker sniffs traffic on the container network

Threat Model Link

Mitigation

• Mitigation ID 4 - Webhook uses TLS encryption for all traffic

  Kyverno uses HTTPS for all webhook traffic.

Threat ID 8 - Attacker carries out a MITM attack on the webhook

Threat Model Link

Mitigation

• Mitigation ID 5 - Webhook mutual TLS authentication is used

  By default, Kyverno generates a CA and X.509 certificates for the webhook registration. A custom CA and certificates can be used as discussed in the configuration guide. Currently, Kyverno does not authenticate the API server. A network policy can be used to restrict traffic to the Kyverno webhook port.

Threat ID 9 - Attacker steals traffic from the webhook via spoofing

Threat Model Link

Mitigation

• Mitigation ID 5 - Webhook mutual TLS authentication is used

  By default, Kyverno generates a CA and X.509 certificates for the webhook registration. A custom CA and certificates can be used as discussed in the configuration guide. Currently, Kyverno does not authenticate the API server. A network policy can be used to restrict traffic to the Kyverno webhook port.

Threat ID 10 - Abusing a mutation rule to create a privileged container

Threat Model Link

Mitigation

• Mitigation ID 6 - All rules are reviewed and tested

  Kyverno rules are Kubernetes resources written in YAML and managed by an OpenAPIv3 schema. This approach makes it easy to understand policy definitions and to apply policy-as-code best practices, like code reviews, to Kyverno policies. The Kyverno CLI provides a test command for executing unit tests as part of a continuous delivery pipeline.

Threat ID 11 - Attacker deploys workloads to namespaces that are exempt from admission control

Threat Model Link

Mitigation

• Mitigation ID 1 - RBAC rights are strictly controlled

  Kyverno RBAC configurations are described in the configuration section. The kyverno:admission-controller role is used by Kyverno to configure webhooks. It is important to limit Kyverno to the required permissions and audit changes in the RBAC roles and role bindings.

  Kyverno does not exempt any Namespaces by default. It allows configuration of exempt Namespaces via a ConfigMap.

Threat ID 12 - Block rule can be bypassed due to missing match (e.g. missing initContainers)

Threat Model Link

Mitigation

• Mitigation ID 6 - All rules are reviewed and tested

  Kyverno rules are Kubernetes resources written in YAML and managed by an OpenAPIv3 schema. This approach makes it easy to understand policy definitions and to apply policy-as-code best practices, like code reviews, to Kyverno policies. The Kyverno CLI provides a test command for executing unit tests as part of a continuous delivery pipeline.

Threat ID 13 - Attacker exploits bad string matching on a blocklist to bypass rules

Threat Model Link

Mitigation

• Mitigation ID 6 - All rules are reviewed and tested

  Kyverno rules are Kubernetes resources written in YAML and managed by an OpenAPIv3 schema. This approach makes it easy to understand policy definitions and to apply policy-as-code best practices, like code reviews, to Kyverno policies. The Kyverno CLI provides a test command for executing unit tests as part of a continuous delivery pipeline.

Threat ID 14 - Attacker uses new/old features of the Kubernetes API which have no rules

Threat Model Link

Mitigation

• Mitigation ID 6 - All rules are reviewed and tested

  Kyverno rules are Kubernetes resources written in YAML and managed by an OpenAPIv3 schema. This approach makes it easy to understand policy definitions and to apply policy-as-code best practices, like code reviews, to Kyverno policies. The Kyverno CLI provides a test command for executing unit tests as part of a continuous delivery pipeline.

Threat ID 15 - Attacker deploys privileged container to node running Webhook controller

Threat Model Link

Mitigation

• Mitigation ID 7 - Admission controller uses restrictive policies to prevent privileged workloads

  The Kyverno policy library contains policies to restrict container privileges and restrict access to host resources. The Pod Security Standards and best practices policies are highly recommended.

Threat ID 16 - Attacker mounts a privileged node hostPath allowing modification of Webhook controller configuration

Threat Model Link

Mitigation

• Mitigation ID 7 - Admission controller uses restrictive policies to prevent privileged workloads

  The Kyverno policy library contains policies to restrict container privileges and restrict access to host resources. The Pod Security Standards and best practices policies are highly recommended.

Threat ID 17 - Attacker has privileged SSH access to cluster node running admission webhook

Threat Model Link

Mitigation

N/A

Threat ID 18 - Attacker uses policies to send confidential data from admission requests to external systems

Threat Model Link

Mitigation

• Mitigation ID 9 - Strictly control external system access

  See Networking for details on securing networking communications for Kyverno.