Kyverno (Greek for “govern”) is a policy engine designed specifically for Kubernetes. Some of its many features include:
- policies as Kubernetes resources (no new language to learn!)
- validate, mutate, generate, or cleanup (remove) any resource
- verify container images for software supply chain security
- inspect image metadata
- match resources using label selectors and wildcards
- validate and mutate using overlays (like Kustomize!)
- synchronize configurations across Namespaces
- block non-conformant resources using admission controls, or report policy violations
- self-service reports (no proprietary audit log!)
- self-service policy exceptions
- test policies and validate resources using the Kyverno CLI, in your CI/CD pipeline, before applying to your cluster
- manage policies as code using familiar tools like
Kyverno allows cluster administrators to manage environment specific configurations independently of workload configurations and enforce configuration best practices for their clusters. Kyverno can be used to scan existing workloads for best practices, or can be used to enforce best practices by blocking or mutating API requests.
How Kyverno works
Kyverno runs as a dynamic admission controller in a Kubernetes cluster. Kyverno receives validating and mutating admission webhook HTTP callbacks from the kube-apiserver and applies matching policies to return results that enforce admission policies or reject requests.
Kyverno policies can match resources using the resource kind, name, label selectors, and much more.
Mutating policies can be written as overlays (similar to Kustomize) or as a RFC 6902 JSON Patch. Validating policies also use an overlay style syntax, with support for pattern matching and conditional (if-then-else) processing.
Policy enforcement is captured using Kubernetes events. Kyverno also reports policy violations for existing resources.
The picture below shows the high-level architecture for Kyverno:
An high availability installation of Kyverno can run multiple replicas, and each replica of Kyverno will have multiple controllers that perform different functions. The
AdmissionReview requests from the Kubernetes API server, and its
Monitor component creates and manages required configurations. The
PolicyController watches policy resources and initiates background scans based on the configured scan interval. The
GenerateController manages the lifecycle of generated resources.
This section will help you install Kyverno and create your first policy.
NoteYour Kubernetes cluster version must be above v1.14 which adds webhook timeouts. Check the compatibility matrix to ensure your version of Kubernetes is supported. To check the version, enter
You have the option of installing Kyverno directly from the latest release manifest or using Helm. The release manifest should only be used for testing purposes; Helm is recommended for production.
To install Kyverno using a specific release:
1kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.8.5/install.yaml
You can also install Kyverno using Helm:
1# Add the Helm repository 2helm repo add kyverno https://kyverno.github.io/kyverno/ 3 4# Scan your Helm repositories to fetch the latest available charts. 5helm repo update 6 7# Install the Kyverno Helm chart into a new namespace called "kyverno" 8helm install kyverno kyverno/kyverno -n kyverno --create-namespace
Add the policy below to your cluster. It contains a single validation rule that requires that all Pods have a
app.kubernetes.io/name label. Kyverno supports different rule types to validate, mutate, generate, cleanup, and verify image configurations. The policy attribute
validationFailureAction is set to
Enforce to block API requests that are non-compliant (using the default value
Audit will report violations but not block requests.)
1kubectl create -f- << EOF 2apiVersion: kyverno.io/v1 3kind: ClusterPolicy 4metadata: 5 name: require-labels 6spec: 7 validationFailureAction: Enforce 8 rules: 9 - name: check-for-labels 10 match: 11 any: 12 - resources: 13 kinds: 14 - Pod 15 validate: 16 message: "label 'app.kubernetes.io/name' is required" 17 pattern: 18 metadata: 19 labels: 20 app.kubernetes.io/name: "?*" 21EOF
Try creating a Deployment without the required label:
1kubectl create deployment nginx --image=nginx
You should see an error:
1error: failed to create deployment: admission webhook "validate.kyverno.svc-fail" denied the request: 2 3resource Deployment/default/nginx was blocked due to the following policies 4 5require-labels: 6 autogen-check-for-labels: 'validation error: label ''app.kubernetes.io/name'' is 7 required. Rule autogen-check-for-labels failed at path /spec/template/metadata/labels/app.kubernetes.io/name/'
NoteKyverno may be configured to exclude system Namespaces like
kyverno. Make sure you create the Deployment in a user-defined Namespace or the
defaultNamespace (testing only).
Although the ClusterPolicy matches on Pods, Kyverno intelligently applies this to all sources capable of generating Pods by default, including the Deployment above.
Create a Pod with the required label. For example, using this command:
1kubectl run nginx --image nginx --labels app.kubernetes.io/name=nginx
This Pod configuration is compliant with the policy and is not blocked.
Congratulations, you’ve just implemented a policy in your Kubernetes cluster!
Clean up by deleting all cluster policies:
1kubectl delete cpol --all