OMNI52
Kyverno Cheatsheet OMNI52™ GmbH

Kyverno
auf einem Blatt.

Dichte Referenz für Senior Platform Engineers und SREs zur Kubernetes-Policy-Engine (CNCF Graduated). Controller-Architektur, CEL-Policy-Typen, Image-Verifikation mit Sigstore, PolicyReports, Abgrenzung zu ValidatingAdmissionPolicy/MutatingAdmissionPolicy, Webhook-Tuning und Anti-Patterns. Keine Einsteiger-Folien.

Vorschau (2 Seiten A4 quer + Brand-Rückseite)

Kyverno Cheatsheet Seite 1: Architektur, Policy-Typen, Validieren mit CEL, Mutieren und Generieren
Kyverno Cheatsheet Seite 2: Image-Verifikation, VAP/MAP-Abgrenzung, PolicyException, PolicyReports, Webhook-Betrieb, Anti-Patterns

PDF herunterladen

Direkter Download, keine Mail-Adresse nötig. CC BY-SA 4.0 — kopieren, drucken, weiterverteilen ist ausdrücklich erlaubt, solange die Quellenangabe sichtbar bleibt.

Kyverno Cheatsheet (PDF, ~100 KB)

Was drin steht

Architektur

Vier Controller (Admission, Background, Reports, Cleanup), dynamisch generierte Webhooks aus den Policy-Matches, Cert-Rotation, HA mit 3 Replicas.

Policy-Typen 1.18

CEL-Engine policies.kyverno.io/v1 (stable seit 1.18): ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy, ImageValidatingPolicy. ClusterPolicy deprecated, Removal 1.20 geplant.

Validieren & Mutieren

validationActions Deny/Audit, Admission- vs. Background-Evaluation, JSON-Mode für CI-Pipelines, ApplyConfiguration/JSONPatch, mutateExisting.

Supply Chain

ImageValidatingPolicy mit Cosign (Key/Keyless) und Notary, SBOM- und in-toto-Attestations, mutateDigest gegen mutable Tags.

VAP/MAP & Exceptions

Präzise Abgrenzung zu K8s-nativen CEL-Policies (VAP GA 1.30, MAP GA 1.36), native VAP-Generierung, PolicyException-Governance, Autogen für Pod-Controller.

Compliance & Betrieb

PolicyReports (wgpolicyk8s.io) als Audit-Evidenz, failurePolicy fail-closed vs. fail-open, Webhook-Timeout, resourceFilters, Anti-Patterns aus der Praxis.

Cheatsheet im Volltext

Derselbe Inhalt wie im PDF — zum Mitlesen, Durchsuchen und direkten Kopieren der YAML-Snippets. Stand: Kyverno v1.18 (Edition 2026.07).

Architektur

Vier Controller, eine Policy-Engine

Admission-Controller (Pflicht): nimmt die Webhook-Callbacks des API-Servers an, führt validate/mutate aus, prüft PolicyExceptions.

Background-Controller: generate- und mutate-existing-Regeln auf Bestandsressourcen (reconciled UpdateRequests). Reports-Controller: erzeugt und pflegt PolicyReports. Cleanup-Controller: löscht Ressourcen nach Zeitplan.

Kyverno gehört in einen dedizierten Namespace — nie nach kube-system. CNCF-Graduated-Projekt (seit März 2026).

Dynamische Webhooks

Kyverno generiert seine Validating-/MutatingWebhookConfigurations selbst aus den match-Blöcken der installierten Policies — nur gematchte Ressourcen erzeugen überhaupt Admission-Calls.

Zertifikate: self-signed, automatische Rotation (CA 1 Jahr, TLS 150 Tage, Renewal ca. 15 Tage vor Ablauf). HA: 3 Replicas für den Admission-Controller; mehr Replicas bedeutet nicht bei jedem Controller mehr Durchsatz.

helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno \
  -n kyverno --create-namespace
kubectl -n kyverno get deploy   # 4 Controller
kubectl get validatingwebhookconfigurations | grep kyverno

Policy-Typen (Stand 1.18)

CEL-Typen: policies.kyverno.io/v1

Seit 1.18 stable: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy, ImageValidatingPolicy. Jeder Typ auch namespaced (NamespacedValidatingPolicy usw.). Ein CR pro Zweck, CEL statt JMESPath/Pattern.

Legacy: ClusterPolicy / Policy

kyverno.io/v1: validate-, mutate-, generate- und verifyImages-Regeln in einem CR. ClusterPolicy cluster-weit, Policy namespaced.

Deprecated seit 1.18 (nur noch Critical Fixes in 1.18/1.19), Removal für 1.20 (Okt 2026) geplant — Neues in CEL-Typen schreiben, Bestand nach Migrations-Guide umziehen.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: {name: require-ns-purpose-label}
spec:
  rules:
    - name: require-ns-purpose-label
      match:
        any:
        - resources: {kinds: [Namespace]}
      validate:
        failureAction: Enforce   # oder Audit
        message: "Label `purpose` ist Pflicht."
        pattern:
          metadata:
            labels:
              purpose: production

Validieren mit CEL

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata: {name: check-labels}
spec:
  validationActions: [Deny]
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: [v1]
        operations: [CREATE, UPDATE]
        resources: [pods]
  validations:
    - message: label 'environment' ist Pflicht
      expression: >-
        'environment' in
        object.metadata.?labels.orValue([])

Enforcement & Modi

validationActions: Deny blockt, Audit protokolliert nur.

spec.evaluation: admission und background getrennt schaltbar; mode: JSON prüft beliebige JSON-/YAML-Payloads auch ausserhalb des Clusters (CI-Pipeline). matchConstraints folgt der API der K8s ValidatingAdmissionPolicy.

Mutieren & Generieren

MutatingPolicy

patchType: ApplyConfiguration (Server-Side-Apply-Merge) oder JSONPatch.

Bestandsressourcen: spec.evaluation.mutateExisting.enabled: true — der Background-Controller mutiert dann bereits existierende Objekte, nicht nur Admission-Traffic.

apiVersion: policies.kyverno.io/v1
kind: MutatingPolicy
metadata: {name: add-label}
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: [v1]
        operations: [CREATE]
        resources: [pods]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: >
          Object{metadata: Object.metadata{
            labels: Object.metadata.labels{
              team: "platform"}}}

GeneratingPolicy

Erzeugt oder klont Ressourcen auf Trigger — Klassiker: Default-NetworkPolicy oder ResourceQuota bei jedem neuen Namespace. Legacy-generate-Regeln laufen über UpdateRequests des Background-Controllers.

Image-Verifikation (Supply Chain)

ImageValidatingPolicy: Sigstore & Notary

Attestors: Cosign (Public Key, Keyless via OIDC issuer/subject, Transparency Log, TUF) und Notary (X.509-Zertifikate, optional TSA).

Attestations: SBOM- und in-toto-Predicates prüfen via verifyAttestationSignatures() und extractPayload(). mutateDigest: ersetzt mutable Tags durch immutable Digests.

apiVersion: policies.kyverno.io/v1
kind: ImageValidatingPolicy
metadata: {name: verify-images}
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: [v1]
        operations: [CREATE]
        resources: [pods]
  matchImageReferences:
    - glob: "registry.example.com/*"
  attestors:
    - name: cosign
      cosign:
        key:
          data: |
            -----BEGIN PUBLIC KEY-----
            ...
            -----END PUBLIC KEY-----
  validations:
    - expression: >-
        images.containers.map(image,
        verifyImageSignatures(image,
        [attestors.cosign])).all(e, e > 0)
      message: "Signatur-Check fehlgeschlagen"

Abgrenzung: K8s-native CEL-Policies

Was der API-Server selbst kann

ValidatingAdmissionPolicy: GA seit K8s 1.30. MutatingAdmissionPolicy: GA seit K8s 1.36.

CEL läuft in-process im kube-apiserver: keine Webhooks, keine Zertifikate, keine Verfügbarkeits-Abhängigkeit von einem Policy-Deployment.

Was Kyverno darüber legt

Background-Scans auf Bestandsressourcen, PolicyReports, PolicyExceptions, generate/cleanup, Image-Signatur-Verifikation, JSON-Mode, Autogen.

ValidatingPolicy ist ein Superset der VAP — und generiert via spec.autogen.validatingAdmissionPolicy.enabled: true eine native VAP, die im API-Server läuft: Kyverno als Management-Layer, Enforcement ohne Webhook-Hop.

PolicyException & Autogen

PolicyException

Gezielte Ausnahme statt aufgeweichter Policy: referenziert Policy + Regel(n) (Wildcard * ok) + Ressourcen-Match. Legacy-Engine: kyverno.io/v2; CEL-Typen: policies.kyverno.io/v1alpha1.

Default: deaktiviert. Aktivierung per Flag enablePolicyException + exceptionNamespace (nur dort dürfen Exceptions liegen) — Erstellung per RBAC und GitOps kontrollieren.

Autogen für Pod-Controller

Pod-Regeln werden automatisch auf Deployment, DaemonSet, StatefulSet, Job, ReplicaSet, ReplicationController und CronJob (via jobTemplate) ausgeweitet — eine Policy statt sieben.

CEL: spec.autogen.podControllers.controllers. Legacy: Annotation pod-policies.kyverno.io/autogen-controllers (none schaltet ab).

PolicyReports (Compliance)

Audit-Evidenz im Cluster

wgpolicyk8s.io/v1alpha2: PolicyReport (namespaced) und ClusterPolicyReport — offenes Format der Kubernetes Policy WG, nicht Kyverno-proprietär.

Results: pass / fail / warn / error / skip. Gefüttert aus Admission-Requests und Background-Scans (Default: stündlich) — deckt auch Bestandsressourcen ab, die nie durch Admission liefen.

kubectl get policyreport -A       # namespaced
kubectl get clusterpolicyreport   # cluster-scoped
kubectl get polr -o wide          # Kurzform
kubectl get polr <name> -o jsonpath=\
'{.results[?(@.result=="fail")]}'

Webhook-Betrieb

failurePolicy: bewusst entscheiden

Default Fail (fail-closed): ist Kyverno down, lehnt der API-Server alle gematchten Requests ab. Sicher, aber ein Verfügbarkeits-Risiko — HA-Replicas und PDB einplanen.

Fail-open global per --forceFailurePolicyIgnore, besser pro Policy abwägen: Security-Gates Fail, Komfort-Mutationen Ignore.

Performance-Tuning

Webhook-Timeout: Default 10s (1–30s) — knapp halten, hängende Admission bremst jedes Deployment.

Namespace-Filter: webhooks.namespaceSelector in der Kyverno-ConfigMap; kube-system und kyverno sind default ausgenommen. resourceFilters [Kind,Namespace,Name]: letzte Verteidigungslinie hinter dem Webhook — gilt nicht für Background-Scans.

Match-Blöcke eng schneiden: was nicht matcht, erzeugt keinen Admission-Call.

Anti-Patterns

Was du nicht tun solltest

Neue Policies als ClusterPolicy: deprecated seit 1.18, Removal für 1.20 geplant — Neues gehört in die CEL-Typen.

Enforce ohne Audit-Phase: neue Policies erst im Audit-Modus fahren, PolicyReports lesen, dann auf Deny/Enforce drehen.

Pauschal fail-open: Ignore überall hebelt Security-Policies bei jedem Kyverno-Ausfall aus.

Wildcard-Matches: jede Admission geht durch den Webhook — Latenz auf jedem API-Call, maximaler Blast-Radius bei Ausfall.

Exceptions ohne Governance: wer PolicyExceptions erstellen darf, hebelt Policies aus — exceptionNamespace + RBAC + Review-Pflicht.

Kyverno neben andere Workloads: dedizierter Namespace ist Vorgabe der Doku — nie nach kube-system deployen.

Aus der OMNI52 Cheatsheet-Fabrik

Verwandte Sheets in dichter Senior-Qualität:
kubernetes-cheatsheet.de — Kubernetes Core
rke2-cheatsheet.de — RKE2-Distribution
rancher-cheatsheet.de — Rancher-Management
istio-cheatsheet.de — Service-Mesh-Layer (Istio in der Tiefe)

Lizenz & Weiterverteilung

CC BY-SA 4.0. Du darfst dieses Cheatsheet kopieren, weiterverteilen, ausdrucken und in eigenen Materialien zitieren. Bedingung: Quellenangabe „Kyverno Cheatsheet — OMNI52 GmbH, kyverno-cheatsheet.de“ bleibt sichtbar, und abgeleitete Werke stehen unter der gleichen Lizenz (Share-Alike).

Nicht erlaubt: Logo, Marken oder den Eindruck zu vermitteln, dass der Inhalt von dir/euch stammt oder dass OMNI52 GmbH die Weiterverwendung sponsort.

Volltext der Lizenz: creativecommons.org/licenses/by-sa/4.0/deed.de.

Kyverno is a trademark of The Linux Foundation; Kyverno is a Cloud Native Computing Foundation (CNCF) Graduated project. Kubernetes is a registered trademark of The Linux Foundation. OMNI52™ is a trademark of OMNI52 GmbH (filed, not yet registered). This website is operated by OMNI52 GmbH and is not affiliated with, endorsed by, or sponsored by The Linux Foundation, the CNCF, or the Kyverno project. “Kyverno” is used in a nominative / descriptive sense to indicate the technology this cheatsheet documents.