# Kyverno Policy Enforcement

Source: https://docs.ops0.com/docs/configurations/kyverno

ops0 integrates with [Kyverno](https://kyverno.io), a Kubernetes-native policy engine, to enforce your ops0 policies directly on clusters. When Kyverno is installed on a cluster and policies are deployed, Kubernetes will automatically validate and block non-compliant resources at admission time.

## How It Works

```
Developer applies resource    →    Kubernetes API Server
                                         │
                               Kyverno Admission Webhook
                                         │
                           ops0 policy deployed to Kyverno
                                         │
                        Allow (compliant) / Deny (violates policy)
```

1. You define policies in ops0 using the Policies module
2. ops0 installs Kyverno on your cluster (one-click)
3. You deploy specific policies to specific clusters
4. Kyverno enforces them at the API server — no resource violating the policy can be created

## Installing Kyverno

### Prerequisites

- A cluster connected to ops0 (see [Add Cluster](https://docs.ops0.com/docs/kubernetes/add-cluster))
- `can_policies` IAM permission

### Installation Steps

1. Go to **Configurations → Kyverno**
2. Select the cluster
3. Click **Enable Kyverno**
4. ops0 installs Kyverno into the `kyverno` namespace and tracks progress

Installation typically takes 1–3 minutes. The cluster card shows the installation status:

| Status | Meaning |
|--------|---------|
| **installing** | Kyverno is being deployed |
| **installed** | Kyverno is running and ready |
| **failed** | Installation failed — check the error message |

### What Gets Installed

ops0 deploys the standard Kyverno distribution into your cluster:

- Kyverno controller (admission webhook)
- CRDs for `Policy`, `ClusterPolicy`, `PolicyReport`, `ClusterPolicyReport`
- Default RBAC for Kyverno's service account

The `kyverno_namespace` defaults to `kyverno`. The installed version is recorded against the cluster for tracking.

### Re-Installation

If Kyverno is already installed (e.g. you installed it manually before connecting to ops0), you can force a re-install to bring it under ops0 management. Toggle the **Force Reinstall** option before clicking **Enable Kyverno**.

## Deploying Policies to a Cluster

Once Kyverno is installed, you can deploy any ops0 policy to the cluster.

1. Go to **Policies → (select a policy)**
2. Click **Deploy to Cluster**
3. Select the target cluster(s) or cluster group
4. Choose enforcement mode: **Audit** or **Enforce**
5. Click **Deploy**

### Enforcement Modes

| Mode | Behavior |
|------|----------|
| **Audit** | Violations are recorded in PolicyReport but resources are still created |
| **Enforce** | Violating resources are rejected at admission — they cannot be created |

Start with **Audit** to understand the impact before switching to **Enforce**.

### Deployment Status

| Status | Meaning |
|--------|---------|
| **pending** | Queued for deployment |
| **deployed** | Policy active on the cluster in Audit mode |
| **enforced** | Policy active in Enforce mode — blocking violations |
| **failed** | Deployment failed |

## Viewing Violations

Kyverno records all policy violations in `PolicyReport` and `ClusterPolicyReport` resources. ops0 surfaces these in the **Configurations → Violations** view.

| Column | Description |
|--------|-------------|
| **Resource** | The Kubernetes resource that violated the policy |
| **Policy** | Which policy was violated |
| **Rule** | The specific rule within the policy |
| **Severity** | Policy severity (low, medium, high, critical) |
| **Message** | Human-readable violation message |
| **Timestamp** | When the violation was recorded |

## Removing a Policy from a Cluster

1. Go to **Configurations → Kyverno → (select cluster)**
2. Find the deployed policy
3. Click **Remove**

The policy is deleted from the cluster. Existing resources already created in violation are not affected — only new admissions are checked.

## Cluster Groups

You can deploy a policy to a **cluster group** rather than individual clusters. Any cluster in the group that has Kyverno installed will receive the policy. New clusters added to the group later will receive the policy automatically.

## Example Policy

A simple policy requiring all pods to have resource limits:

```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-resource-limits
      match:
        any:
        - resources:
            kinds:
              - Pod
      validate:
        message: "Resource limits are required for all containers."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"
```

Create this as an ops0 policy, then deploy it to your clusters with one click.

## Troubleshooting

Installation stuck at "installing"

Check the `kyverno` namespace on your cluster: `kubectl get pods -n kyverno`. If pods are in `Pending`, the cluster may lack resources or the image pull is failing. Review pod events for details.

Policy deployed but not enforcing

Verify the policy is in **Enforce** mode (not Audit). Check that the Kyverno webhook is healthy: `kubectl get validatingwebhookconfigurations`. A misconfigured webhook will silently allow all resources.

Existing resources not blocked

Kyverno only enforces at admission time. Resources that existed before policy deployment are not retroactively blocked — they will appear in the Violations view if you run a policy audit scan.

Legitimate resource rejected

Switch the policy to **Audit** mode temporarily to unblock the team. Review the violation message to understand which rule triggered, then either update the policy rule or the resource to comply.