Security

Security Processes and Guidelines

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 kyverno-security@googlegroups.com 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_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_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, follow the steps below.

  1. Install Cosign
  2. Configure the Kyverno signature repository:
1export COSIGN_REPOSITORY=ghcr.io/kyverno/signatures
  1. Verify the image:
1COSIGN_EXPERIMENTAL=1 cosign verify ghcr.io/kyverno/kyverno:<release_tag> | jq

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

 1Verification for ghcr.io/kyverno/kyverno:<release_tag> --
 2The following checks were performed on each of these signatures:
 3  - The cosign claims were validated
 4  - Existence of the claims in the transparency log was verified offline
 5  - Any certificates were verified against the Fulcio roots.
 6[
 7  {
 8    "critical": {
 9      "identity": {
10        "docker-reference": "ghcr.io/kyverno/kyverno"
11      },
12      "image": {
13        "docker-manifest-digest": "sha256:fb6b62f1a3a53b32be9cc508224e9b12e022665b472cc2e7069cfe12505b836b"
14      },
15      "type": "cosign container image signature"
16    },
17    "optional": {
18      "1.3.6.1.4.1.57264.1.2": "push",
19      "1.3.6.1.4.1.57264.1.3": "ef269c050f7ed78eff9cb2b905760beee8c65986",
20      "1.3.6.1.4.1.57264.1.4": "releaser",
21      "1.3.6.1.4.1.57264.1.5": "kyverno/kyverno",
22      "1.3.6.1.4.1.57264.1.6": "refs/tags/<release_tag>",
23      "Bundle": {
24        "SignedEntryTimestamp": "MEQCIBaIXxkCW5z0MiZCjmBkcw+3Qtokv4JviRXUJsSvCNqaAiAWV9WB+fJnQQMBUMEEkeSSUO/Xjuowkr6l3hVfnSv/Ng==",
25        "Payload": {
26          "body": "<snip>",
27          "integratedTime": 1666022906,
28          "logIndex": 5288524,
29          "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"
30        }
31      },
32      "Issuer": "https://token.actions.githubusercontent.com",
33      "Subject": "https://github.com/kyverno/kyverno/.github/workflows/reuse.yaml@refs/tags/<release_tag>",
34      "ref": "ef269c050f7ed78eff9cb2b905760beee8c65986",
35      "repo": "kyverno/kyverno",
36      "workflow": "releaser"
37    }
38  }
39]

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

 1$ COSIGN_EXPERIMENTAL=1 cosign verify-attestation --type slsaprovenance ghcr.io/kyverno/kyverno:v1.9.0-beta.1 | jq .payload -r | base64 --decode | jq
 2
 3Verification for ghcr.io/kyverno/kyverno:v1.9.0-beta.1 --
 4The following checks were performed on each of these signatures:
 5  - The cosign claims were validated
 6  - Existence of the claims in the transparency log was verified offline
 7  - Any certificates were verified against the Fulcio roots.
 8Certificate subject:  https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.4.0
 9Certificate issuer URL:  https://token.actions.githubusercontent.com
10GitHub Workflow Trigger: push
11GitHub Workflow SHA: da8297b3c0ace39088061ec84a63e7a2efccbbaa
12GitHub Workflow Name: releaser
13GitHub Workflow Trigger kyverno/kyverno
14GitHub Workflow Ref: refs/tags/v1.9.0-beta.1
15{
16  "_type": "https://in-toto.io/Statement/v0.1",
17  "predicateType": "https://slsa.dev/provenance/v0.2",
18  "subject": [
19    {
20      "name": "ghcr.io/kyverno/kyverno",
21      "digest": {
22        "sha256": "36d26e870854991783b8eff71969c67d43747b4c5ac97fd5db7a71c1e2761d30"
23      }
24    }
25  ],
26  "predicate": {
27    "builder": {
28      "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.4.0"
29    },
30    "buildType": "https://github.com/slsa-framework/slsa-github-generator/container@v1",
31    "invocation": {
32      "configSource": {
33        "uri": "git+https://github.com/kyverno/kyverno@refs/tags/v1.9.0-beta.1",
34        "digest": {
35          "sha1": "da8297b3c0ace39088061ec84a63e7a2efccbbaa"
36        },
37        "entryPoint": ".github/workflows/release.yaml"
38      },
39      "parameters": {},
40      "environment": {
41      <snip>

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:

1COSIGN_REPOSITORY=ghcr.io/kyverno/sbom cosign download sbom ghcr.io/kyverno/kyverno:<release_tag>

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

1COSIGN_REPOSITORY=ghcr.io/kyverno/sbom cosign download sbom ghcr.io/kyverno/kyverno:<release_tag> > kyverno.sbom.json

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 ArtifactHub page along with an auto-generated Security Report generated by ArtifactHub 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:

1kubectl get clusterroles,roles -A | grep kyverno

It is important to limit Kyverno to the required permissions and audit changes in the RBAC Roles and RoleBindings. In particular, the default kyverno:view and kyverno:generate Roles can be customized to match your requirements.

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

Webhooks

Use the following command to view all Kyverno Roles:

1kubectl get mutatingwebhookconfigurations,validatingwebhookconfigurations | grep kyverno

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.

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:

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

Threat Model Link

Mitigations:

Threat ID 3 - Attacker exploits misconfiguration of webhook to bypass

Threat Model Link

Mitigation:

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:webhook 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. In particular, the default kyverno:view and kyverno:generate roles can be customized to match your requirements.

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

Threat Model Link

Mitigation:

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

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

Threat Model Link

Mitigation

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

Threat Model Link

Mitigation

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 installation section. The kyverno:webhook 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. In particular, the default kyverno:view and kyverno:generate roles can be customized to match your requirements.

    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 continious 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 continious 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 continious delivery pipeline.

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

Threat Model Link

Mitigation

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

Threat Model Link

Mitigation

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

Last modified January 17, 2023 at 11:46 AM PST: 1.9 documentation updates (#733) (702f6d2)