---
title: "Install and Use Kyverno in Kubernetes | Hostman Docs"
description: "Install Kyverno in your Hostman Kubernetes cluster, test policies in Audit mode, enforce them with Deny, and safely remove the addon."
---

> For the complete documentation index for AI agents, see [llms.txt](https://hostman.com/llms.txt).

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

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

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

```shell
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

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

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

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

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

Create a namespace for the test:

```shell
kubectl create namespace kyverno-example
```

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

```shell
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](https://kyverno.io/docs/).

Apply the manifest:

```shell
kubectl apply -f require-environment-label.yaml
```

### Test the Policy in Audit Mode

Create a `ConfigMap` without the required label:

```shell
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:

```shell
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:

```shell
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:

```shell
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:

```shell
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](https://kyverno.io/docs/guides/reports/).

### Switch the Policy to Deny

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

```shell
validationActions:
   - Deny
```

Re-apply the manifest:

```shell
kubectl apply -f require-environment-label.yaml
```

Try to create another `ConfigMap` without the label:

```shell
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

Delete the test policy and the namespace:

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

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

## Remove Kyverno

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

Export the policies to a YAML file:

```shell
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:

```shell
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

Delete the policies while Kyverno is still running:

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

If you used cleanup policies, delete them too:

```shell
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

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.