What Happens If Your Cluster Has No “Rules of the Game”?
When I first started operating Kubernetes, I believed RBAC was enough to protect the system. But reality was different. Developers often accidentally ran containers as root or forgot to set CPU/RAM limits in their rush to deploy. Once, a service without resource limits consumed all node resources, causing several other critical services to hang.
Instead of manually checking for errors or reminding everyone individually, I chose Kyverno to automate this process. Kyverno is a Policy Engine designed specifically for Kubernetes. It acts like a “police officer” monitoring every resource pushed into the cluster. Anything that doesn’t meet the standards is either blocked or automatically corrected.
The best part about Kyverno is that it uses YAML. If you’re already familiar with writing K8s manifests, you’ll master Kyverno in 15 minutes. You don’t need to learn a complex language like Rego, which is required for OPA (Open Policy Agent).
Install Kyverno and Try It Out in 5 Minutes
The fastest way to deploy Kyverno is by using Helm. You only need a few simple commands in your terminal:
# Add the Kyverno Helm repo
helm repo add kyverno https://kyverno.github.io/kyverno/
# Update the repo and install
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespaceLet’s try creating a real-world policy: Require every Pod to have an ‘owner’ label. This label helps us identify who is responsible for a resource when an issue occurs.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-owner-label
spec:
validationFailureAction: Enforce
rules:
- name: check-for-owner-label
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Error: You must add an 'owner' label to identify the Pod manager."
pattern:
metadata:
labels:
owner: "?*"After applying it with kubectl apply -f policy.yaml, anyone attempting to create a Pod without the owner label will receive an immediate error message. The system will reject the request right at the API Server gateway.
The Power Trio: Validate, Mutate, and Generate
Kyverno does more than just block things. It provides three flexible mechanisms for specific use cases:
1. Validate – Strict Gatekeeping
This is the most common feature. You set a standard, and Kyverno checks if the resource meets it. For example: Preventing containers from running in privileged mode to avoid the risk of taking over the physical node.
You can choose Audit mode to log warnings or Enforce mode to block the violation entirely.
2. Mutate – Auto-remediating Configurations
This feature is extremely helpful for supporting developers. Suppose your team often forgets to set imagePullPolicy: Always. Instead of making them fix it, Kyverno will automatically inject this configuration into the YAML file before the Pod is created.
It’s like a silent butler, personally perfecting the small missing details in your blueprints.
3. Generate – Infrastructure Automation
Every time you create a new Namespace for a project, you usually need to create additional resources like NetworkPolicy, ResourceQuota, or Secrets. Kyverno will automatically “spawn” these resources as soon as it detects a new Namespace.
For sensitive Secrets, I often use Toolcraft’s password generator to create secure strings. This tool processes entirely on the client-side, so I feel safe copying them into K8s Secrets.
Deploying Pod Security Standards (PSS) Without the “Pain”
Kubernetes defines a set of PSS security standards with three levels: Privileged, Baseline, and Restricted. Applying these standards helps you pass security audits like SOC2 or PCI-DSS more easily.
Kyverno provides a built-in library of policy templates for PSS. You just need to install and activate the Restricted level for Production environments. It will automatically check various criteria, such as forbidding hostPath access or requiring a read-only root filesystem.
Pro tip: When first applying policies, use Audit mode for about 1-2 weeks. Monitor the reports to see how many existing Pods are in violation before switching to Enforce. This prevents the entire system from being blocked due to a lack of adaptation time.
Real-world Experience for Running Kyverno Smoothly
After implementing it for large-scale systems, I’ve gathered four important notes:
- Exclude system Namespaces: Absolutely exclude
kube-systemand Kyverno’s own namespace. If your policy is too strict and accidentally blocks CoreDNS, your cluster will “crash” within minutes. - Monitor performance: Kyverno processes Admission Requests via Webhooks. Each request typically adds about 10-30ms of latency. If you have hundreds of policies, increase the resources (CPU/RAM) for the Kyverno Pods.
- Test thoroughly locally: Use the Kyverno CLI with the
kyverno testcommand to verify policies in your CI/CD pipeline before pushing them to the live cluster. - Don’t over-rely on Mutate: Automating too many configuration changes can confuse developers because the actual running state differs from the YAML they wrote. Always provide accompanying documentation.
Kyverno has helped me reduce silly configuration errors by 80% and significantly improved system security. It’s not just a tool; it’s a way to practice Policy as Code professionally. If you’re managing K8s, try installing Kyverno today for better sleep at night.
