Kyverno


Kyverno is a policy engine for Kubernetes. It checks and modifies cluster resources based on policies you define, so you can enforce rules without changing your applications. For example, you can block privileged pods, require resource limits and labels, add annotations automatically, or create default resources in new namespaces.

Policies are Kubernetes resources that you write as YAML manifests and apply with kubectl. Kyverno supports four main actions:

  • Validate: checks whether a resource meets the policy requirements.
  • Mutate: modifies a resource, for example by adding labels or annotations.
  • Generate: creates resources based on the rules you set.
  • Cleanup: deletes resources based on policy conditions or after a set period of time.

Install Kyverno
Copy link

Kyverno has no dependencies on other addons. You don't need an Ingress or dedicated nodes with a public IP address.

  1. Go to the Kubernetes section and select your cluster.
  2. Open the Addons tab and click Kyverno.
  3. (Optional) Turn on Advanced setup to change the configuration.
  4. Click Install and wait for the installation to complete.

Verify the Installation
Copy link

Kyverno is installed in the kyverno namespace. List the pods with the command:

kubectl get pods -n kyverno

With the default settings, four pods should be running, one for each controller. Make sure all of them have the Running status and show 1/1 in the READY column. 

Kyverno Components
Copy link

Kyverno runs as four controllers, each in its own pod:

Component

Purpose

kyverno-admission-controller

Validates and modifies resources when they are created or updated, using admission webhooks.

kyverno-background-controller

Creates resources based on generate rules and modifies existing resources based on mutateExisting rules in the background.

kyverno-cleanup-controller

Deletes resources based on cleanup policies, including CleanupPolicy, and the cleanup.kyverno.io/ttl label.

kyverno-reports-controller

Generates PolicyReport and ClusterPolicyReport reports and scans resources in the background.

Safe Policy Rollout
Copy link

Some policies can block the installation of other addons from the dashboard or break addons that are already installed. To avoid this, roll out every new policy in three steps:

  1. Limit the scope of the policy to the resources and namespaces you need.
  2. Start in Audit mode. Resources that violate the policy are still created, and the violations appear in reports.
  3. Review the reports. When you're sure the policy doesn't interfere with normal cluster operation, switch it to blocking mode: Deny for ValidatingPolicy, or Enforce for validation rules in ClusterPolicy and Policy.

Default Exclusions
Copy link

Kyverno processes resources that match the conditions of your policies, except for the exclusions built into the addon. When you install Kyverno from the dashboard, it doesn't check the following:

  • The kube-system and kyverno namespaces.
  • Internal resource types, including Node, Event, ReplicaSet, APIService, and TokenReview.
  • The addons' own resources: their Deployment, Service, ConfigMap, Secret, and other objects.

Usage Example
Copy link

In this walkthrough, you'll create a policy that requires the environment label on ConfigMap objects in a dedicated namespace. You'll test it in Audit mode first, and then switch to blocking mode.

Create the Policy
Copy link

Create a namespace for the test:

kubectl create namespace kyverno-example

Create a file named require-environment-label.yaml:

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
 name: require-environment-label
spec:
 validationActions:
   - Audit
 matchConstraints:
   namespaceSelector:
     matchLabels:
       kubernetes.io/metadata.name: kyverno-example
   resourceRules:
     - apiGroups: [""]
       apiVersions: [v1]
       operations: [CREATE, UPDATE]
       resources: [configmaps]
 matchConditions:
   - name: is-example-config
     expression: "object.metadata.name.startsWith('example-')"
 validations:
   - expression: "has(object.metadata.labels) && 'environment' in object.metadata.labels"
     message: "Specify the environment label for the ConfigMap."

In this manifest:

  • namespaceSelector limits the check to the kyverno-example namespace.
  • resourceRules limits the check to ConfigMap objects.
  • matchConditions selects objects whose names start with example- and excludes the automatically created kube-root-ca.crt ConfigMap.
  • validations checks for the environment label. The label can have any value.

ValidatingPolicy uses the CEL expression language for conditions. For more details on the parameters of this policy type, see the Kyverno documentation.

Apply the manifest:

kubectl apply -f require-environment-label.yaml

Test the Policy in Audit Mode
Copy link

Create a ConfigMap without the required label:

kubectl create configmap example-config -n kyverno-example --from-literal=mode=test

Because the policy runs in Audit mode, Kyverno still creates the resource and records the violation in a report. After a short while, check the results:

kubectl get policyreports -n kyverno-example \
 -o custom-columns='RESOURCE:.scope.name,PASS:.summary.pass,FAIL:.summary.fail,RESULT:.results[0].result,MESSAGE:.results[0].message'

In the example-config row, RESULT is fail, and MESSAGE says that the label is required. This means the require-environment-label policy detected the violation.

Now add the missing label:

kubectl label configmap example-config -n kyverno-example environment=test

Reports are updated asynchronously. The state of the resource and the result in PolicyReport can temporarily differ, so right after you add the label, the report may still show fail.

To watch the report update, run:

kubectl get policyreports -n kyverno-example --watch \
 -o custom-columns='RESOURCE:.scope.name,PASS:.summary.pass,FAIL:.summary.fail,RESULT:.results[0].result,MESSAGE:.results[0].message'

Wait until RESULT in the example-config row changes to pass, then press Ctrl+C to stop watching.

To view reports for resources in all namespaces and for cluster-level resources, run:

kubectl get policyreports -A
kubectl get clusterpolicyreports

Reports reflect the current state of your resources and don't keep a history of all violations. For more details, see the Kyverno reports documentation.

Switch the Policy to Deny
Copy link

Once the reports confirm that the policy works as expected, switch it to blocking mode. In require-environment-label.yaml, replace Audit with Deny:

validationActions:
   - Deny

Re-apply the manifest:

kubectl apply -f require-environment-label.yaml

Try to create another ConfigMap without the label:

kubectl create configmap example-without-label -n kyverno-example --from-literal=mode=test

After the policy takes effect, Kyverno rejects the request and returns the message "Specify the environment label for the ConfigMap." To allow resources that violate the policy again, switch back to Audit and re-apply the manifest.

Clean Up the Test Resources
Copy link

Delete the test policy and the namespace:

kubectl delete -f require-environment-label.yaml
kubectl delete namespace kyverno-example

This doesn't remove the Kyverno addon from your cluster.

Remove Kyverno
Copy link

Before you remove Kyverno, delete all the policies you created. Removing the addon also deletes its CRDs (custom resource definitions), so no policies are preserved in the cluster. If you might need them later, back up their manifests first.

The commands below cover the most common policy types. If you also use other types, such as NamespacedValidatingPolicy, add them to the commands.

(Optional) Back Up Your Policies
Copy link

Export the policies to a YAML file:

kubectl get vpol,mpol,gpol,ivpol,dpol,cpol,pol -A -o yaml > kyverno-policies-backup.yaml

This command saves ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy, DeletingPolicy, ClusterPolicy, and Policy resources.

If you used CleanupPolicy or ClusterCleanupPolicy, back them up separately:

kubectl get cleanuppolicies.kyverno.io,clustercleanuppolicies.kyverno.io -A -o yaml > kyverno-cleanup-policies-backup.yaml

Make sure the commands finished without errors and that the files contain all the policies you need.

Delete the Policies
Copy link

Delete the policies while Kyverno is still running:

kubectl delete vpol,mpol,gpol,ivpol,dpol,cpol,pol -A --all

If you used cleanup policies, delete them too:

kubectl delete cleanuppolicies.kyverno.io,clustercleanuppolicies.kyverno.io -A --all

These commands delete all policies of the listed types in all namespaces and at the cluster level.

Delete the Addon
Copy link

Make sure all the policies are deleted, and then:

  1. Go to the Kubernetes section and select your cluster.
  2. Open the Addons tab.
  3. Click the three dots on the Kyverno card.
  4. Click Delete addon.
  5. Confirm the action.