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.
- Go to the Kubernetes section and select your cluster.
- Open the Addons tab and click Kyverno.
- (Optional) Turn on Advanced setup to change the configuration.
- 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 kyvernoWith 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 |
|
|
Validates and modifies resources when they are created or updated, using admission webhooks. |
|
|
Creates resources based on |
|
|
Deletes resources based on cleanup policies, including |
|
|
Generates |
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:
- Limit the scope of the policy to the resources and namespaces you need.
- Start in Audit mode. Resources that violate the policy are still created, and the violations appear in reports.
- Review the reports. When you're sure the policy doesn't interfere with normal cluster operation, switch it to blocking mode:
DenyforValidatingPolicy, orEnforcefor validation rules inClusterPolicyandPolicy.
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-systemandkyvernonamespaces. - Internal resource types, including
Node,Event,ReplicaSet,APIService, andTokenReview. - 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-exampleCreate 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:
namespaceSelectorlimits the check to thekyverno-examplenamespace.resourceRuleslimits the check toConfigMapobjects.matchConditionsselects objects whose names start withexample-and excludes the automatically createdkube-root-ca.crtConfigMap.- 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.yamlTest 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=testBecause 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=testReports 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 clusterpolicyreportsReports 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:
   - DenyRe-apply the manifest:
kubectl apply -f require-environment-label.yamlTry to create another ConfigMap without the label:
kubectl create configmap example-without-label -n kyverno-example --from-literal=mode=testAfter 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-exampleThis 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.yamlThis 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.yamlMake 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 --allIf you used cleanup policies, delete them too:
kubectl delete cleanuppolicies.kyverno.io,clustercleanuppolicies.kyverno.io -A --allThese 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:
- Go to the Kubernetes section and select your cluster.
- Open the Addons tab.
- Click the three dots on the Kyverno card.
- Click Delete addon.
- Confirm the action.