Kyverno: Kubernetes-native policy engine — inclusief de wijzigingen in v1.20

Kyverno is een Kubernetes-native policy engine: in tegenstelling tot OPA/Gatekeeper (dat een aparte taal, Rego, gebruikt) worden Kyverno-policies geschreven als gewone Kubernetes-resources. Dat maakt de instapdrempel laag — als je YAML kent, kun je grotendeels direct aan de slag. Kyverno kan policies valideren, muteren (automatisch aanvullen/corrigeren) en genereren (automatisch gerelateerde resources aanmaken), allemaal via admission control of achtergrondscanning.

Hoe Kyverno in de praktijk werkt

Installatie met Helm

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

helm install kyverno kyverno/kyverno 
  --namespace kyverno 
  --create-namespace

kubectl get pods -n kyverno

Belangrijk: de overgang van ClusterPolicy naar CEL-gebaseerde policy-types

Dit is op dit moment de belangrijkste ontwikkeling binnen Kyverno, en direct relevant als je nu met het schrijven van policies begint. Kyverno gebruikte historisch JMESPath — een eigen, Kyverno-specifieke expressietaal — binnen één breed ClusterPolicy-object. Sinds versie 1.14/1.15 (2025) zijn hier CEL-gebaseerde (Common Expression Language) policy-types naast gezet: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy en DeletingPolicy — elk gericht op één specifieke taak, in plaats van alles in één breed object.

CEL is dezelfde taal die Kubernetes zelf gebruikt voor zijn eigen ValidatingAdmissionPolicy sinds versie 1.30 — door hierop aan te sluiten wint Kyverno aan prestaties en sluit het beter aan bij hoe Kubernetes zich native ontwikkelt.

De tijdlijn samengevat

• v1.14/v1.15 (2025) — de nieuwe CEL-gebaseerde policy-types worden geïntroduceerd, aanvankelijk in bèta
• v1.17 (februari 2026) — de CEL-types worden gepromoveerd naar v1 (stabiel/productierijp); ClusterPolicy en CleanupPolicy worden officieel als deprecated gemarkeerd
• v1.18 (mei 2026) — eerste release na Kyverno's CNCF-graduatie; belangrijke SSRF-beveiligingsfixes voor HTTP-aanroepen vanuit policies; nog geen breaking changes
• v1.20 (gepland oktober 2026) — de legacy ClusterPolicy- en CleanupPolicy-types worden volledig verwijderd. Op het moment van schrijven is deze versie nog niet uitgebracht, maar wel al aangekondigd; wie nu nog met de oude JMESPath-syntax begint, bouwt bewust technische schuld op.

Praktisch advies: Schrijf nieuwe policies vanaf nu altijd in de CEL-gebaseerde types (ValidatingPolicy, MutatingPolicy, enz.), ook al draai je nog een oudere Kyverno-versie waarin ClusterPolicy nog werkt. Heb je een bestaande set ClusterPolicy-resources, plan dan een migratie vóór versie 1.20 uitkomt — Kyverno biedt een officiële migratiegids met een veld-voor-veld mapping van de oude naar de nieuwe syntax.

Een policy in de oude stijl (ClusterPolicy, JMESPath)

Ter illustratie — en om te herkennen wat je op oudere clusters nog tegenkomt:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-team-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-team-label
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Het label 'team' is verplicht."
        pattern:
          metadata:
            labels:
              team: "?*"

Dezelfde policy in de nieuwe stijl (ValidatingPolicy, CEL)

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: require-team-label
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
        operations: ["CREATE", "UPDATE"]
  validations:
    - expression: "has(object.metadata.labels) && 'team' in object.metadata.labels"
      message: "Het label 'team' is verplicht."

De CEL-expressie leest bijna als gewone code, en sluit direct aan bij hoe je condities ook in native Kubernetes ValidatingAdmissionPolicy-resources zou schrijven — één taal, minder contextwisseling voor platformteams.

Mutatie: automatisch aanvullen in plaats van alleen weigeren

apiVersion: policies.kyverno.io/v1
kind: MutatingPolicy
metadata:
  name: add-default-resources
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
        operations: ["CREATE"]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: >
          Object{
            spec: Object.spec{
              containers: object.spec.containers.map(c,
                Object.spec.containers{
                  name: c.name,
                  resources: Object.spec.containers.resources{
                    limits: Object.spec.containers.resources.limits{cpu: "500m", memory: "256Mi"}
                  }
                }
              )
            }
          }

Image-verificatie met Sigstore/Cosign

Een van Kyverno's sterkste toepassingen is het afdwingen dat alleen getekende, geverifieerde container-images gedeployed mogen worden — essentieel voor supply chain-beveiliging.

apiVersion: policies.kyverno.io/v1alpha1
kind: ImageValidatingPolicy
metadata:
  name: verify-image-signatures
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
  images:
    - name: alle-containers
      expression: "object.spec.containers.map(c, c.image)"
  attestors:
    - name: mijn-sigstore-sleutel
      cosign:
        key:
          data: |
            -----BEGIN PUBLIC KEY-----
            ...
            -----END PUBLIC KEY-----

Achtergrondscanning: bestaande resources controleren

Naast admission control (nieuwe/gewijzigde resources tegenhouden) kan Kyverno ook al bestaande resources periodiek scannen tegen het actieve beleid, en de resultaten wegschrijven als een PolicyReport — nuttig om te zien hoe compliant een cluster al is vóórdat je enforcement daadwerkelijk activeert.

kubectl get policyreport -Ankubectl get clusterpolicyreport

Kyverno versus OPA/Gatekeeper

Beide zijn volwaardige CNCF-projecten voor policy-as-code binnen Kubernetes. De keuze hangt vaak af van de bestaande expertise in een team: teams die al Rego kennen (bijvoorbeeld vanuit een bredere OPA-inzet buiten Kubernetes) neigen naar Gatekeeper; teams die vooral Kubernetes-native willen blijven werken kiezen vaker voor Kyverno.

Veelgestelde vragen

Moet ik nu al mijn ClusterPolicy-resources migreren?

Niet per se onmiddellijk, maar wel vóór versie 1.20 (gepland oktober 2026) uitkomt en je naar die versie wilt upgraden. Bestaande ClusterPolicy-resources blijven werken in 1.17, 1.18 en 1.19 — het is een aangekondigde, geleidelijke deprecatie, geen abrupte breuk. Wacht je te lang met upgraden na de release van 1.20, dan werken je oude policies simpelweg niet meer.

Is er een geautomatiseerde manier om te migreren?

Kyverno biedt een officiële migratiegids met een veld-voor-veld mapping tussen de oude en nieuwe syntax. Volledige automatische conversie is niet gegarandeerd voor complexere policies, vooral bij mutatie- en generate-regels — reken op handmatige controle per policy.

Werkt Kyverno ook op OpenShift?

Ja, Kyverno draait op elk conform Kubernetes-platform, inclusief OpenShift. Let bij OpenShift wel op de interactie met Security Context Constraints (SCC) — beide mechanismen kunnen overlappende zaken afdwingen, dus stem je Kyverno-policies af op wat SCC al regelt om dubbel werk en verwarrende foutmeldingen te voorkomen.