Ein Cluster ist nur so diszipliniert wie die Regeln, die beim Deploy tatsächlich greifen. RBAC entscheidet, wer etwas anlegen darf. Ob das Angelegte auch den eigenen Standards entspricht, steht auf einem anderen Blatt. Genau hier setzt Admission Control an: ein Prüfschritt, der jedes Objekt abfängt, bevor es im Cluster landet. Ich zeige, wie das mit Kyverno praktisch aussieht.

Warum Admission Control

Kubernetes hat zwei eingebaute Admission-Webhook-Typen: validating und mutating. Ein Validating Webhook sagt ja oder nein zu einem Objekt. Ein Mutating Webhook verändert es, bevor es gespeichert wird. Beide laufen im kube-apiserver, bevor das Objekt in etcd geschrieben wird. Das ist der entscheidende Punkt: Was der Webhook ablehnt, existiert nie. Es gibt keinen halb angelegten Pod, den man später aufräumen muss.

Selbst Webhooks zu schreiben ist Arbeit. Man braucht einen HTTP-Server, TLS-Zertifikate und Logik für jedes Feld. Kyverno nimmt das ab. Policies sind YAML, keine kompilierte Sprache, und Kyverno bringt den Webhook selbst mit.

Kyverno installieren

helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

Nach der Installation läuft der Admission-Controller als Deployment im Namespace kyverno. Policies sind ab jetzt normale Cluster-Ressourcen, die man mit kubectl apply einspielt und mit kubectl get clusterpolicy wieder findet.

Eine erste Regel: keine latest-Tags

Der Klassiker. Ein Image mit dem Tag latest ist nicht reproduzierbar, weil sich dahinter jederzeit ein anderer Digest verbergen kann. Diese Policy lehnt jeden Pod ab, dessen Image auf latest endet oder gar kein Tag trägt.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Ein explizites Image-Tag ist Pflicht, latest ist verboten."
        pattern:
          spec:
            containers:
              - image: "!*:latest"

Das Feld validationFailureAction steuert das Verhalten. Enforce blockt den Deploy. Audit lässt ihn durch und schreibt stattdessen einen PolicyReport. Mehr dazu weiter unten.

Nicht nur ablehnen, sondern ergänzen

Die eigentliche Stärke zeigt sich bei Mutating Policies. Statt einen Deploy abzulehnen, weil ein Feld fehlt, ergänzt Kyverno es. Das folgende Beispiel setzt automatisch einen restriktiven SecurityContext, wenn keiner definiert wurde.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-securitycontext
spec:
  rules:
    - name: set-runasnonroot
      match:
        any:
          - resources:
              kinds: [Pod]
      mutate:
        patchStrategicMerge:
          spec:
            securityContext:
              runAsNonRoot: true
              seccompProfile:
                type: RuntimeDefault

Der Vorteil: Teams müssen nicht jede Sicherheitsvorgabe kennen. Der Cluster setzt sinnvolle Defaults, und wer es besser weiß, überschreibt sie bewusst. Das ist deutlich freundlicher als eine Wand aus Fehlermeldungen bei jedem Deploy.

Audit zuerst, Enforce später

Eine Policy im Enforce-Modus auf einen laufenden Cluster loszulassen ist ein guter Weg, sich unbeliebt zu machen. Bestehende Workloads, die gegen die Regel verstoßen, fliegen beim nächsten Rollout raus. Der saubere Weg ist Audit zuerst.

Im Audit-Modus sammelt Kyverno Verstöße als PolicyReport, ohne etwas zu blocken. So sieht man, wie viele Objekte betroffen wären, bevor die Regel scharf geschaltet wird.

kubectl get policyreport -A
kubectl get clusterpolicyreport

Erst wenn die Reports sauber sind oder die Ausnahmen bekannt, stellt man validationFailureAction auf Enforce. Für Ausnahmen gibt es das PolicyException-Objekt, mit dem sich einzelne Namespaces oder Workloads gezielt ausnehmen lassen, ohne die ganze Policy aufzuweichen.

Fazit

Admission Control verschiebt die Kontrolle an den einzigen Punkt, an dem sie lückenlos greift: den Moment, bevor ein Objekt im Cluster existiert. Kyverno macht das ohne eigenen Code, mit YAML, das im gleichen Repo liegt wie der Rest der Infrastruktur. Ich fange immer mit Audit an, schaue mir die Reports an und schalte dann Regel für Regel scharf. Wer die Verbindung von Policy und Lieferkette weiterdenken will, findet auf digital-business.blog mehr zum Thema Governance in der Pipeline.