CNCF TAG-Security Kyverno Security Self Assessment

Table of contents

• Metadata
  • Security links
• Overview
  • Background
  • Goals
  • Non-goals
• Self-assessment use
• Security functions and features
• Project compliance
• Secure development practices
• Security issue resolution
• Appendix

Metadata

Security links

Overview

Kyverno helps secure and automates configurations using policies defined as Kubernetes custom resources. It operates as a Kubernetes admission controller and provides command-line tools for off-cluster use. Additionally, Kyverno has been extended with new policy types (ValidatingPolicy, ImageValidatingPolicy, MutatingPolicy) that utilize CommonExpressionLanguage (CEL) to support non-Kubernetes resources, enabling policy validation for any JSON or YAML payload including Terraform files, Dockerfiles, cloud configurations, and service authorization requests.

Background

Kubernetes has a declarative configuration management system that allows users to specify the desired state of resources which Kubernetes controllers continuously reconcile with the current system state. For flexibility, and to address a wide set of use cases, Kubernetes provides several configuration options for each resource.

While this is powerful, it also creates a few challenges:

1. Only a small subset of configuration options are commonly used.
2. Kubernetes configurations are not secure by default. Security and best practices need to be configured for workloads.
3. A resource’s configurations is shared across organizational roles (dev-sec-ops) and chances of misconfigurations, or lack of proper configuration, increase as there is no clear ownership. Whether developers, operators, or security engineers are responsible for more advanced configuration settings may not be obvious.

Goals

The goal is to enforce security policies across Kubernetes resources to prevent insecure configurations and ensure compliance. User-defined YAML and CEL policies are enforced through admission control to prevent non-compliant Kubernetes resources from being created or modified, providing immediate feedback to users. If the admission controller is unavailable, CLI tools and background scanning provide alternative enforcement mechanisms to maintain security posture. Kyverno also provides automation through mutation and generation capabilities to automatically fix configurations and create required resources, simplifying security management. CLI tools extend this enforcement to non-Kubernetes resources like Terraform files and Dockerfiles.

Non-goals

Kyverno is NOT designed to address Kubernetes security flaws, as it cannot protect against vulnerabilities in the Kubernetes API server or underlying infrastructure and Kyverno’s policy enforcement may be bypassed if Kubernetes has a security flaw. Kyverno does not enforce security requirements that weren’t explicitly defined, it enforces only the policies that users define. Kyverno does not replace Kubernetes RBAC, as RBAC controls access while Kyverno enforces policy compliance. Kyverno also does not replace Kubernetes’ built-in policy controls like ValidatingAdmissionPolicies and MutatingAdmissionPolicies, but complements these native controls with additional features such as comprehensive reporting, exception management, and periodic scanning.

Self-assessment use

This self-assessment is created by the Kyverno team to perform an internal analysis of the project’s security. It is not intended to provide a security audit of Kyverno, or function as an independent assessment or attestation of Kyverno’s security health.

This document serves to provide Kyverno users with an initial understanding of Kyverno’s security, where to find existing security documentation, Kyverno plans for security, and general overview of Kyverno security practices, both for development of Kyverno as well as security of Kyverno.

This document provides the CNCF TAG-Security with an initial understanding of Kyverno to assist in a joint-review, necessary for projects under incubation. Taken together, this document and the joint-review serve as a cornerstone for if and when Kyverno seeks graduation and is preparing for a security audit.

Logical Architecture

The following diagram shows the logical architecture for Kyverno. Each major component is described below:

Kyverno consists of four main controllers that work together to provide comprehensive policy management capabilities. Each controller handles specific aspects of policy processing, from admission control to background operations and cleanup tasks.

Admission Controller

• Receives AdmissionReview requests from the Kubernetes API server through validating and mutating webhooks.
• Processes validate, mutate, and image validating rules.
• Manages and renews certificates as Kubernetes Secrets for webhook use through the embedded Cert Renewer.
• Manages and configures webhook rules dynamically based on installed policies through the embedded Webhook Controller.
• Performs policy validation for the Policy, ClusterPolicy, ValidatingPolicy, ImageValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy, and PolicyException custom resources.
• Processes Policy Exceptions.
• Generates EphemeralReport and ClusterEphemeralReport intermediary resources for further processing by the Reports Controller.
• Generates UpdateRequest intermediary resources for further processing by the Background Controller.

Reports Controller

• Responsible for creation and reconciliation of the final PolicyReport and ClusterPolicyReport custom resources.
• Performs background scans and generates, processes, and converts EphemeralReport and ClusterEphemeralReport intermediary resources into the final policy report resources.

Background Controller

• Processes generate and mutate-existing rules of the Policy or ClusterPolicy, and the mutate-existing functionality of the MutatingPolicy and GeneratingPolicy.
• Processes policy add, update, and delete events.
• Processes and generates UpdateRequest intermediary resources to generate or mutate the final resource.
• Generates EphemeralReport and ClusterEphemeralReport intermediary resources for further processing by the Reports Controller.

Cleanup Controller

• Processes CleanupPolicy and DeletingPolicy resources.
• Performs policy validation for the CleanupPolicy and ClusterCleanupPolicy custom resources through a webhook server.
• Reconciles its webhook through a webhook controller.
• Manages and renews certificates as Kubernetes Secrets for use in the webhook.
• Creates and reconciles CronJobs used as the mechanism to trigger cleanup.
• Handles the cleanup by deleting resources from the Kubernetes API.

Physical Architecture

Kyverno can be installed using a Helm chart or YAML files (see installation doc ).

The diagram below shows the Kyverno physical architecture:

A standard Kyverno installation consists of a number of different components, some of which are optional:

Deployments

• Admission controller (required): The main component of Kyverno which handles webhook callbacks from the API server for verification, mutation, Policy Exceptions, and the processing engine.
• Background controller (optional): The component responsible for processing of generate and mutate-existing rules.
• Reports controller (optional): The component responsible for handling of Policy Reports.
• Cleanup controller (optional): The component responsible for processing of Cleanup Policies and Deleting Policies.

Services

• Services needed to receive webhook requests.
• Services needed for monitoring of metrics.

ServiceAccounts

• One ServiceAccount per controller to segregate and confine the permissions needed for each controller to operate on the resources for which it is responsible.

ConfigMaps

• ConfigMap for holding the main Kyverno configuration.
• ConfigMap for holding the metrics configuration.

Secrets

• Secrets for webhook registration and authentication with the API server.

Roles and Bindings

• Roles and ClusterRoles, Bindings and ClusterRoleBindings authorizing the various ServiceAccounts to act on the resources in their scope.

Webhooks

• ValidatingWebhookConfigurations for receiving both policy and resource validation requests.
• MutatingWebhookConfigurations for receiving both policy and resource mutating requests.

CustomResourceDefinitions

• CRDs which define the custom resources corresponding to policies, reports, and their intermediary resources.

Security functions and features

Kyverno operates as an webhook admission controller.

Threat Modeling

A threat model for admission controllers is published and maintained by the Kubernetes SIG Security:

• Kubernetes Admission Controller Threat Model
• Blog post

The Kyverno security document references this threat model and discusses mitigations and best practices:

https://main.kyverno.io/docs/security/#threat-model

Project compliance

Kyverno does not currently document meeting particular compliance standards.

Secure development practices

The Kyverno project follows established CNCF and OSS best practices for code development and delivery.

Development Pipeline

All code is maintained in Git and changes must be reviewed by maintainers and must pass all unit and e2e tests. Code changes are submitted via Pull Requests (PRs) and must be signed. Commits to the main branch are not allowed.

Artifacts

The Kyverno container images are hosted in GitHub Container Registry (GHCR). Container images are signed using Sigstore Cosign ( https://main.kyverno.io/docs/security/#verifying-kyverno-container-images .)

The Kyverno Helm chart is hosted in ArtifactHub. There is a pending issue to to sign the Helm Chart using Sigstore Cosign ( https://github.com/kyverno/kyverno/issues/2758) .

The Kyverno installation YAMLs are hosted in the GitHub repository.

A Software Bill of Materials (SBOM) is produced and made available for each release ( https://main.kyverno.io/docs/security/#fetching-the-sbom-for-kyverno) .

Communication Channels.

• Internal: GitHub Discussions
• Inbound: #kyverno slack channel , mailing list
• Outbound: #kyverno slack channel , mailing list
• Security email group: kyverno-security

Security processes

Kyverno’s processes for security issue resolution, responsible disclosure, vulnerability response, and incident response are documented at:

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

A security email alias kyverno-security is available for security disclosures and related communications.

Appendix

Known Issues Over Time

All Kyverno security related issues (both fixes and enhancements) are labeled with “security” and can be queried using:

https://github.com/kyverno/kyverno/labels/security

CII Best Practices

The Kyverno project has passed the OpenSSF Scorecard check and is actively working towards achieving silver/gold level certification. Progress is being tracked via issue 10908 .

Related Projects / Vendors

OPA/Gatekeeper is another CNCF project that acts as an admission controller and supports policy management. It uses Rego as its policy language.

A detailed comparison is available at: https://neonmirrors.net/post/2021-02/kubernetes-policy-comparison-opa-gatekeeper-vs-kyverno/ .