Kyverno — Policy as Code for Kubernetes
Kyverno is a policy engine for Kubernetes that uses native YAML instead of a new language. Validate, mutate, and generate resources with policies written as Kubernetes resources.
Installation agent prête
Cet actif peut être installé après choix du runtime, vérification du plan et exécution de la commande adaptée.
npx -y tokrepo@latest install e6f1ef60-3558-11f1-9bc6-00163e2b0d79 --target codexÀ exécuter après confirmation du plan en dry-run.
What it is
Kyverno is a policy engine designed for Kubernetes that uses native YAML instead of a proprietary policy language. It validates, mutates, and generates Kubernetes resources using policies defined as custom resources. Unlike OPA/Gatekeeper which requires learning Rego, Kyverno policies look like standard Kubernetes manifests.
Cluster administrators enforcing security baselines, platform teams standardizing resource configurations, and DevOps engineers automating Kubernetes best practices use Kyverno to codify and enforce rules across their clusters.
How it saves time or tokens
Without a policy engine, enforcing standards like 'all pods must have resource limits' or 'no containers can run as root' requires manual review or custom admission webhooks. Kyverno automates enforcement at the admission control layer. Its mutation capabilities can automatically inject sidecars, add labels, or set defaults, eliminating manual configuration steps. Since policies are YAML, the learning curve is minimal for teams already working with Kubernetes.
How to use
- Install Kyverno via Helm:
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace
- Apply a validation policy:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-labels
spec:
validationFailureAction: Enforce
rules:
- name: check-team-label
match:
any:
- resources:
kinds:
- Pod
validate:
message: 'The label team is required.'
pattern:
metadata:
labels:
team: '?*'
- Apply with
kubectl apply -f policy.yaml. Any pod without a 'team' label will be rejected.
Example
# Mutation policy: automatically add resource limits
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-default-resources
spec:
rules:
- name: add-limits
match:
any:
- resources:
kinds:
- Pod
mutate:
patchStrategicMerge:
spec:
containers:
- (name): '*'
resources:
limits:
memory: 256Mi
cpu: 500m
requests:
memory: 128Mi
cpu: 250m
Related on TokRepo
- DevOps Tools -- explore DevOps and infrastructure tools
- Security Tools -- discover security policy and compliance tools
Common pitfalls
- Setting validationFailureAction to 'Enforce' blocks non-compliant resources immediately. Start with 'Audit' to see violations in reports before enforcing.
- Kyverno runs as an admission webhook. If it goes down, new resource creation may be blocked. Configure failurePolicy and resource limits to ensure high availability.
- Mutation policies apply in order. When multiple policies modify the same resource, the final state depends on policy execution order. Test with kubectl apply --dry-run to verify.
Questions fréquentes
Kyverno uses native Kubernetes YAML for policies, while OPA/Gatekeeper requires learning Rego, a separate policy language. Kyverno also supports mutation and generation of resources, which Gatekeeper does not natively handle. For teams already comfortable with Kubernetes YAML, Kyverno has a significantly lower learning curve.
Yes. Kyverno mutation policies can add labels, inject sidecars, set default resource limits, add environment variables, and modify any field in a Kubernetes resource. Mutations happen at admission time before the resource is persisted.
Kyverno primarily operates on admission (new and updated resources). For existing resources, use Kyverno policy reports to audit compliance. The generate feature can create new resources based on triggers, but existing non-compliant resources are not automatically modified.
Generate policies create new Kubernetes resources when a trigger condition is met. For example, when a new namespace is created, a generate policy can automatically create default network policies, resource quotas, or role bindings in that namespace.
Kyverno generates PolicyReport and ClusterPolicyReport resources that list violations. In Audit mode, violations are recorded but not blocked. You can query these reports with kubectl or integrate with monitoring tools like Prometheus using the Kyverno metrics endpoint.
Sources citées (3)
- Kyverno GitHub— Kubernetes policy engine using native YAML
- Kyverno Documentation— Validate, mutate, and generate Kubernetes resources
- CNCF Kyverno— CNCF graduated project for Kubernetes policy management
En lien sur TokRepo
Fil de discussion
Actifs similaires
OPA Gatekeeper — Policy Controller for Kubernetes Admission
OPA Gatekeeper enforces customizable policies on Kubernetes resources at admission time, using constraint templates written in Rego to validate and mutate API requests.
Conftest — Test Structured Config with Open Policy Agent
A CLI tool for writing tests against structured configuration data using the Rego policy language. Conftest validates Kubernetes manifests, Terraform plans, Dockerfiles, and any structured format against custom policies.
Datree — Policy Enforcement for Kubernetes Configurations
Prevent Kubernetes misconfigurations from reaching production. Datree validates manifests against built-in and custom rules in CI or the CLI.
Calico — Kubernetes Networking and Network Security
A high-performance networking and network policy engine for Kubernetes that provides pod networking, network policy enforcement, and optional eBPF data plane for zero-overhead observability.