ops0 integrates with Kyverno, 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.
Developer applies resource → Kubernetes API Server
│
Kyverno Admission Webhook
│
ops0 policy deployed to Kyverno
│
Allow (compliant) / Deny (violates policy)
can_policies IAM permissionkyverno namespace and tracks progressInstallation 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 |
ops0 deploys the standard Kyverno distribution into your cluster:
Policy, ClusterPolicy, PolicyReport, ClusterPolicyReportThe kyverno_namespace defaults to kyverno. The installed version is recorded against the cluster for tracking.
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.
Once Kyverno is installed, you can deploy any ops0 policy to the cluster.
| 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.
| 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 |
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 |
The policy is deleted from the cluster. Existing resources already created in violation are not affected — only new admissions are checked.
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.
A simple policy requiring all pods to have resource limits:
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.
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.kubectl get validatingwebhookconfigurations. A misconfigured webhook will silently allow all resources.