Kyverno-Policies einführen, ohne dass eure Deployments stehen bleiben
Kyverno ist ein Admission Controller, der eure Sicherheitsregeln als Kubernetes-Ressource ablegt und bei jedem Deployment prüft. Eine Regel besteht aus Match, Bedingung und Aktion: validate lehnt ab, mutate ergänzt, generate legt Objekte an. Startet jede Policy im Modus Audit, lest die PolicyReports über einen vollen Release-Zyklus, korrigiert die Workloads, und schaltet erst dann auf Enforce. Wer sofort scharf schaltet, blockiert produktive Deployments.
Was ist Kyverno und was macht ein Admission Controller im Cluster?
Kyverno ist eine Policy-Engine für Kubernetes, die als Admission Controller läuft. Der API-Server ruft vor dem Speichern jedes Objekts einen Webhook auf. Kyverno prüft das Objekt gegen eure Regeln und antwortet auf drei mögliche Arten: durchlassen, ablehnen, oder verändert zurückgeben.
Die Regeln selbst sind Kubernetes-Ressourcen: eine ClusterPolicy gilt clusterweit, eine Policy nur im eigenen Namespace. Beides ist YAML, liegt in Git und wird per GitOps ausgerollt wie jedes andere Manifest. Keine zweite Sprache, kein zweiter Rollout-Weg.
Wichtig für die Planung: Admission greift beim Schreiben, nicht zur Laufzeit. Ein Pod, der bereits läuft, wird von einer neuen Regel nicht angefasst. Er fällt erst auf, wenn er neu erzeugt wird: beim nächsten Rollout, beim Scale-up oder nach einem Node-Neustart.
Warum Regeln, die nur im Wiki stehen, gebrochen werden
Weil sie niemand liest, wenn es eilig ist. Ein Fall, der uns in fast jedem Cluster begegnet: In der internen Hardening-Checkliste steht dokumentiert, dass keine privilegierten Container laufen dürfen. Ein Team installiert einen Monitoring-Agenten per Helm-Chart, und das Chart setzt in den Defaults hostPath und privileged auf true, weil es Kernel-Metriken liest. Niemand liest die values.yaml eines fremden Charts zeilenweise. Der Verstoß entsteht aus einem Default, nicht aus Böswilligkeit.
Der zweite Grund ist die Ausnahme. Sobald ein Workload die Regel brechen muss, wird das im Chat freigegeben, und ein halbes Jahr später weiß niemand mehr, wer das genehmigt hat. Als Kyverno-Regel ist die Ausnahme eine PolicyException in Git: mit Autor, Datum, Geltungsbereich und Review.
Wenn ihr die Regelliste noch nicht habt, nehmt die Kubernetes-Hardening-Checkliste und übersetzt daraus die ersten sechs Regeln.
Wie ihr eine Kyverno-Policy schreibt: validate, mutate, generate
Jede Regel hat denselben Aufbau: ein match für die betroffenen Ressourcen, optionale preconditions, und genau eine Aktion.
- validate prüft und lehnt ab oder meldet nur. Beispiel: securityContext.privileged darf nicht true sein, jeder Container braucht ein Limit für CPU und Speicher.
- mutate ergänzt oder ändert das Objekt, bevor es gespeichert wird. Beispiel: ein fehlendes Pflicht-Label setzen, readOnlyRootFilesystem erzwingen, seccompProfile nachtragen. Der unterschätzte Hebel, weil die Teams ihre Manifeste nicht anfassen müssen.
- generate legt abhängige Objekte an. Beispiel: bei jedem neuen Namespace automatisch eine NetworkPolicy mit default deny. Wie diese Netzwerkregeln aussehen müssen, steht auf NetworkPolicies.
Eine Regel kann auch verlangen, dass ein Image aus einer freigegebenen Registry stammt oder signiert ist. Wie die Prüfung dahinter funktioniert, behandelt Image Scanning.
Jedes Ergebnis landet als PolicyReport im Namespace des geprüften Workloads und ist per kubectl abfragbar. Ihr braucht kein externes Dashboard, um zu sehen, was eine Regel treffen würde.
Audit oder Enforce: was passiert, wenn ihr zu früh scharf schaltet
Der Unterschied ist ein Feld. Auf Audit schreibt Kyverno nur einen Report, das Objekt geht durch. Auf Enforce wird jedes Objekt abgelehnt, das die Regel verletzt.
Unterschätzt wird dabei: Admission trifft jeden Schreibvorgang, nicht nur euren Deploy. Ein ReplicaSet, das nach einem Node-Ausfall Pods nachzieht, ein HPA-Scale-up um drei Uhr nachts, ein Rollout nach einem Node-Upgrade, alles läuft durch dieselbe Prüfung. Eine Policy, die ihr nachmittags scharf schaltet, wirkt harmlos, solange niemand deployt. Auffallen wird sie in der Nacht, in der ein Node stirbt und die Pods nicht wieder hochkommen.
Die zweite Falle ist die failurePolicy des Webhooks. Auf Fail lehnt der API-Server Admission-Anfragen ab, wenn Kyverno nicht antwortet. Auf Ignore laufen ungeprüfte Objekte durch. Wir fahren die Engine deshalb mit mehreren Replicas, engem Namespace-Selector und Ausnahmen für kube-system.
Kyverno, OPA Gatekeeper oder Pod Security Admission: was passt zu eurem Cluster?
Kurzantwort: Pod Security Admission als Basislinie in jedem Namespace, Kyverno für alles darüber hinaus, Gatekeeper dann, wenn im Team schon Rego-Wissen liegt. Die drei schließen sich nicht aus.
| Kriterium | Kyverno | OPA Gatekeeper | Pod Security Admission |
|---|---|---|---|
| Regelsprache | YAML als Kubernetes-Ressource | Rego in ConstraintTemplates | Label am Namespace |
| Reichweite | beliebige Ressourcen | beliebige Ressourcen | nur Pods |
| Objekte verändern | Kern-Feature, mutate | separates Mutation-Feature | nicht möglich |
| Objekte erzeugen | generate | nicht vorgesehen | nicht vorgesehen |
| Reporting im Cluster | PolicyReport je Namespace | Status am Constraint | Warnung in der API-Antwort |
| Aufwand im Betrieb | Engine und Webhook betreiben, Regeln im Git-Review | Engine und Webhook betreiben, Rego-Kompetenz halten | im API-Server enthalten, nichts zu betreiben |
| Typischer Einsatz | eigene Regeln über den Standard hinaus, Defaults setzen | komplexe Logik über mehrere Ressourcen hinweg | Basislinie privileged, baseline, restricted |
Wer heute nichts davon betreibt, fängt mit Pod Security Admission an. Kyverno kommt dazu, sobald die erste Regel gebraucht wird, die kein Pod-Feld betrifft: erlaubte Registries, Pflicht-Labels, verbotene Image-Tags.
Mit welchen Regeln ihr anfangt und in welcher Reihenfolge ihr sie ausrollt
Nehmt sechs Regeln, nicht sechzig. Ein fertiger Katalog erzeugt Reports, die niemand liest.
| Regel | Was sie verhindert | Typischer Bruch beim Umschalten auf Enforce |
|---|---|---|
| kein privileged | Container mit allen Kernel-Rechten, Ausbruch auf den Node | Monitoring- und Storage-Agenten aus fremden Helm-Charts |
| kein hostPath | Zugriff auf das Dateisystem des Nodes | Log-Sammler, CSI-Treiber, alte Legacy-Mounts |
| kein hostNetwork und keine hostPorts | Umgehung der Netzwerktrennung auf dem Node | Ingress-Controller, die bewusst so laufen |
| keine latest-Tags | nicht reproduzierbare Rollouts | interne Tools und Cronjobs ohne Versionierung |
| nur freigegebene Registries | ungeprüfte Images aus dem Internet | Sidecars und Init-Container, die aus Docker Hub ziehen |
| Limits für CPU und Speicher gesetzt | ein Workload verdrängt alle anderen vom Node | Batch-Jobs und Entwicklungs-Namespaces |
Engine installieren, die sechs Regeln als ClusterPolicy in Git legen, alle im Modus Audit. Kube-system und die Plattform-Namespaces von Anfang an ausnehmen.
PolicyReports lesen, mindestens über einen vollen Release-Zyklus. Jeder Treffer bekommt eine von zwei Antworten: Workload korrigieren, oder Ausnahme begründen und als PolicyException in Git legen.
Regeln ohne offene Treffer auf Enforce stellen, erst in den nicht-produktiven Namespaces, dann in der Produktion. Der Rest bleibt auf Audit.
mutate ergänzen, damit die Teams nichts nachtragen müssen: fehlende Labels, readOnlyRootFilesystem, seccompProfile.
Nächste Welle, wieder maximal sechs Regeln, wieder erst Audit. Erweitert wird nur, wenn die vorherige Welle auf Enforce steht.
Policies als Code: warum ein Senior-Engineer damit 30 bis 50 Cluster betreut
Ein Senior-Engineer betreut bei uns 30 bis 50 Cluster mit GitOps. Eine Regel, die im Wiki steht, braucht pro Cluster einen Menschen, der sie kennt und im Review durchsetzt. Dieser Mensch skaliert nicht. Eine Regel, die als Kyverno-Policy in Git liegt, gilt in allen 30 bis 50 Clustern gleichzeitig, ab dem Merge, auch nachts um drei.
Der Unterschied zwischen einer Richtlinie und einer Policy ist nicht der Inhalt. Es ist die Frage, ob ein Mensch danebenstehen muss.
Praktisch heißt das: ein Repository mit den Policies, ein Overlay je Cluster-Klasse für die Ausnahmen, ein Pull Request als einziger Weg, eine Regel zu ändern. Wer diesen Betrieb nicht selbst aufbauen will, gibt ihn ab: unser Retainer startet ab 2.500 EUR im Monat und deckt Regelpflege, Ausnahme-Reviews und die Engine ab, Servicezeit Mo-Fr 08:00-18:00 MEZ. Mehr dazu unter Managed Kubernetes.
Was Kyverno nicht löst
Ein Admission Controller prüft Objekte, keine Prozesse. Vier Dinge bleiben offen, und sie sind wichtiger als die siebte Policy:
- Kyverno erkennt keine Schwachstelle im Image. Eine Regel kann ein unsigniertes oder ungescanntes Image abweisen, die Prüfung selbst passiert woanders, siehe Image Scanning.
- Kyverno segmentiert kein Netzwerk. Es kann eine NetworkPolicy per generate anlegen, die Wirkung hängt an eurem CNI, siehe NetworkPolicies.
- Kyverno räumt keine Rechte auf. Wer im Cluster cluster-admin trägt, behält das, siehe RBAC.
- Kyverno sieht nichts zur Laufzeit. Ein Prozess, der im laufenden Container startet, ist kein Admission-Ereignis, siehe Container Security.
Was der Angriffsflächen-Check ab 850 EUR an euren Policies prüft, und was er nicht ist
Abgrenzung
Der Angriffsflächen-Check ab 850 EUR ist kein Pentest. Wir greifen euren Cluster nicht an, wir brechen nicht aus Containern aus und wir liefern keinen Exploit-Nachweis. Der Check ist ein Konfigurations-Review von 0,5 bis 1 Personentag: Wir lesen eure Policies, Manifeste und Cluster-Konfiguration und gleichen sie gegen den CIS-Benchmark ab.
Sagen können wir daraus, welche Regel fehlt, welche zu weit gefasst ist und welche seit Monaten im Audit-Modus hängt, ohne je etwas zu verhindern. Nicht sagen können wir, ob eine konkrete Schwachstelle in eurer Umgebung tatsächlich ausnutzbar ist. Braucht ihr diesen Nachweis, weil ein Kunde oder ein Audit ihn verlangt, machen wir das nicht selbst, sondern holen einen Partner für einen echten Penetrationstest dazu. Ein Prüftestat erteilen wir ebenfalls nicht, das können nur akkreditierte Stellen.
Wollt ihr den Stand mit Blick auf NIS2 dokumentiert haben, das über das BSIG am 06.12.2025 in Kraft getreten ist, ist der Compliance-Snapshot für 1.250 EUR der passende Umfang, siehe Kubernetes Compliance.
Verwandte Seiten im Security-Zweig
- Kubernetes Security: Übersicht und Preise, vom Self-Check bis zum laufenden Betrieb.
- Trivy und Image Scanning: welche CVEs aus euren Images im Cluster überhaupt erreichbar sind.
- Network Policies: Trennung im Netz, die eine Admission-Regel nicht leistet.
- Kubernetes RBAC: wer was darf, bevor eine Policy den Rest prüft.
- Container Security: Härtung des Containers selbst.
- Hardening-Checkliste: die bestehende Liste zum Durcharbeiten.
Häufige Fragen zu Kyverno und Policy-Enforcement
Ist Kyverno besser als OPA Gatekeeper?
Nicht besser, sondern anders. Kyverno-Regeln sind YAML, ihr braucht keine eigene Sprache. Gatekeeper nutzt Rego, das ist mächtiger bei komplexer Logik und dafür schwerer zu lesen und zu reviewen. Wenn euer Team Kubernetes-YAML im Griff hat und die Regeln in Git liegen sollen, kommt ihr mit Kyverno schneller in den produktiven Betrieb. Bei bestehendem Rego-Wissen bleibt Gatekeeper die richtige Wahl.
Brauchen wir Kyverno, wenn Pod Security Admission schon aktiv ist?
Pod Security Admission deckt genau drei Stufen ab: privileged, baseline, restricted. Das ist ein guter Grundschutz und endet dort. Alles, was ihr darüber hinaus erzwingen wollt, geht damit nicht: erlaubte Registries, Pflicht-Labels, Ressourcen-Limits, verbotene Image-Tags. Dafür braucht ihr Kyverno oder Gatekeeper. Sinnvoll ist beides parallel: PSA als Basislinie im Namespace, Kyverno für alles Spezifische.
Was passiert, wenn wir eine Policy sofort auf Enforce stellen?
Der Admission Controller lehnt jedes Objekt ab, das die Regel verletzt. Betroffen sind nicht nur neue Deployments: Auch ein Rollout nach einem Node-Neustart oder ein HPA-Scale-up scheitert, wenn das Pod-Template die Regel bricht. Das fällt meist nachts auf. Deshalb läuft jede neue Policy erst im Audit-Modus, bis die PolicyReports über einen vollen Release-Zyklus sauber sind.
Legt Kyverno unseren Cluster lahm, wenn der Webhook ausfällt?
Das hängt an der failurePolicy. Steht sie auf Fail und der Webhook antwortet nicht, werden Admission-Anfragen abgelehnt, und zwar clusterweit. Steht sie auf Ignore, laufen Deployments durch, aber ungeprüft. Beide Varianten haben einen Preis. Wir fahren Kyverno deshalb mit mehreren Replicas, engem Namespace-Selector und Ausnahmen für kube-system, damit ein Ausfall nicht die Steuerungsebene mitnimmt.
Mit wie vielen Policies fangen wir an?
Mit so wenigen, wie ihr in einem Release-Zyklus sauber bekommt. Nehmt die Regeln, die echte Angriffswege schließen: kein privileged, kein hostPath, kein hostNetwork, keine latest-Tags, nur freigegebene Registries, gesetzte Ressourcen-Limits. Ein fertiger Katalog aus dem Netz erzeugt dagegen Reports, die niemand liest, und blockiert am Ende die falschen Workloads. Erweitert wird erst, wenn die erste Welle auf Enforce steht.
Was kostet es, wenn ihr euch unsere Policies anschaut?
Der Angriffsflächen-Check startet ab 850 EUR und dauert 0,5 bis 1 Personentag. Wir lesen eure Kyverno- oder Gatekeeper-Regeln, gleichen sie gegen den CIS-Benchmark ab und zeigen, welche Regel im Audit-Modus hängt und welche produktiv nichts mehr verhindert. Wollt ihr den Stand mit Blick auf NIS2 dokumentiert haben, ist das der Compliance-Snapshot für 1.250 EUR.
So fangt ihr an: erst der Self-Check, dann die Manifeste
Wir haben 17 Anbieter angesehen, die Kubernetes-Security verkaufen. 0 von 17 haben ein buchbares Produkt mit Preis. Deshalb steht unserer hier: Der Angriffsflächen-Check startet ab 850 EUR und dauert 0,5 bis 1 Personentag. Die vollständige Leiter vom kostenlosen Self-Check bis zum laufenden Betrieb steht auf dem Hub Kubernetes Security.
Vor dem Gespräch könnt ihr eine Frage selbst beantworten: Wie viele eurer Kyverno-Regeln stehen heute noch auf Audit? Steht dort die Mehrheit, kennt ihr den Befund bereits. Wenn ihr wissen wollt, welche davon zuerst auf Enforce kann: Erstgespräch buchen. Servicezeit Mo-Fr 08:00-18:00 MEZ.