Kyverno: Policy as Code für automatisierte Compliance-Prüfung

TL;DR

• Kyverno ist eine Kubernetes-native Policy Engine, mit der Sie Sicherheits- und Betriebsrichtlinien direkt als YAML definieren und automatisiert als Admission-Controller im Cluster durchsetzen können.
• Mit klar strukturierten Guardrails für Security (z. B. Container-Isolation, vertrauenswürdige Registries), Reliability (z. B. Ressourcen-Management) und Operation (z. B. Storage-, LoadBalancer- und Backup-Regeln) wird Compliance zu einem wiederholbaren, überprüfbaren Prozess.
• Regulatorische Anforderungen aus GDPR Art. 32 (seit dem 25.05.2018 anwendbar), der NIS‑2-Richtlinie (mit Umsetzungsfrist der EU-Mitgliedstaaten bis zum 17.10.2024) und dem BSI IT-Grundschutz lassen sich mit Policy as Code systematisch in Ihrem Kubernetes-Cluster abbilden.
• Praxisnah umgesetzt bedeutet das: Deployments werden schon beim Einspielen gegen Policies geprüft; fehlerhafte Konfigurationen werden mit klaren, technischen Hinweisen abgewiesen – bevor sie zum Risiko in Produktion werden.
• ayedo nutzt Kyverno als zentrales Policy-as-Code-Werkzeug, liefert vordefinierte Guardrails und Reporting-Funktionen und unterstützt Sie dabei, Kyverno Policies als festen Bestandteil Ihrer Delivery- und Compliance-Strategie zu etablieren.

---

Kyverno im Überblick: Policy as Code, wo es hingehört

Kyverno ist eine Policy Engine, die speziell für Kubernetes entwickelt wurde. Anders als generische Policy-Frameworks setzt Kyverno vollständig auf Kubernetes-Objekte und YAML. Das passt gut in eine Welt, in der Infrastruktur, Applikationen und Security-Konfigurationen bereits als Code beschrieben werden.

Statt eine neue Policy-Sprache zu erfinden, nutzt Kyverno bekannte Konzepte:

• Policies werden als Kubernetes-Ressourcen definiert.
• Die Syntax ist YAML-basiert und orientiert sich an den Feldern der Kubernetes-Objekte, die Sie ohnehin deployen.
• Kyverno arbeitet als Admission Controller: Jede Änderung an Ressourcen wird vor dem Speichern im API-Server geprüft – und bei Bedarf blockiert oder modifiziert.

Das Ergebnis: Richtlinien sind gleichwertige „Erstbürger“ in Ihrem Cluster, versionierbar in Git, durch Reviews abgesichert und automatisiert wirksam.

Policy-Typen in Kyverno

Kyverno unterstützt drei zentrale Policy-Funktionen, die sich kombinieren lassen:

• Validierung: Regeln prüfen eingehende Ressourcen (z. B. Deployments, Pods, Namespaces). Wenn eine Policy verletzt wird, kann Kyverno die Änderung im Enforce-Modus ablehnen oder im Audit-Modus nur melden.
• Mutation: Regeln ergänzen oder korrigieren Konfigurationen automatisch – etwa Standard-Labels oder Default-Security-Settings.
• Generierung: Regeln sorgen dafür, dass bestimmte Objekte automatisch erzeugt werden, wenn ein anderer Trigger eintritt (z. B. automatische NetworkPolicy, sobald ein Namespace erstellt wird).

Besonders wichtig aus Compliance-Sicht sind der Policy-Modus und das Reporting:

• Im Enforce-Modus werden nicht-konforme Changes blockiert.
• Im Audit-Modus werden Verstöße protokolliert, aber nicht verhindert – ideal zum Einführen neuer Regeln mit geringem Risiko.
• Policy-Reports geben Ihnen eine Übersicht, welche Ressourcen wo gegen welche Policies verstoßen – Grundlage für strukturierte Verbesserungen.

Diese Kombination macht Kyverno zu einem praktischen Enabler für automatisierte Compliance: Policies werden einmal definiert und laufen dann kontinuierlich im Hintergrund mit.

---

Guardrails-Kategorien: Security, Reliability, Operation

Um Kyverno sinnvoll im Unternehmen zu verankern, hat es sich bewährt, Policies als Guardrails zu strukturieren – Leitplanken, die sichere und robuste Konfigurationen erzwingen, ohne die Autonomie der Entwicklungsteams unnötig einzuschränken.

Typischerweise lassen sich Guardrails in drei Kategorien einsortieren: Security, Reliability und Operation.

Security Guardrails: Container-Kontrolle und Trusted Registries

Security-Guardrails adressieren direkte Sicherheitsrisiken in Workloads und Infrastruktur. Typische, in vielen Organisationen etablierte Regeln sind:

Verbot privilegierter Container und Root-User

Viele Container-Images sind ab Werk so gebaut, dass Prozesse als Root laufen. Das erhöht die Ausnutzbarkeit von Schwachstellen erheblich. Ein zentrales Guardrail sorgt deshalb dafür, dass:

• Container nicht privilegiert laufen,
• kein Root-User verwendet wird,
• Security-Kontexte explizit gesetzt sind.

Kyverno prüft an dieser Stelle die relevanten Felder der Pod- und Container-Spezifikation. Wenn ein Deployment versucht, einen Root-Container zu starten, wird der Request abgelehnt oder – im Audit-Modus – zumindest mit einem klaren Hinweis protokolliert.

Diese Art von Guardrail zahlt direkt auf Kontrollanforderungen wie ISO 27001 und BSI APP.4.4 ein und unterstützt Sie bei der Umsetzung von Zugriffsbeschränkungen auf Betriebssystemebene.

Keine „latest“-Tags und kontrollierte Versionen

Ein weiteres klassisches Sicherheits- und Compliance-Problem sind unversionierte oder mutable Image-Tags wie „latest“, „dev“ oder „prod“. Sie erschweren:

• Nachvollziehbarkeit: Welche Version läuft wirklich?
• Reproduzierbarkeit: Lässt sich ein Vorfall akkurat nachstellen?
• Rollbacks: Kann gezielt auf die vorherige, bekannte Version zurückgegangen werden?

Mit einem Kyverno-Guardrail lassen sich Images ohne expliziten, stabilen Tag einfach ablehnen. So stellen Sie sicher, dass nur klar identifizierbare Versionen in Produktion landen. Diese Praxis unterstützt Anforderungen an Change-Management und Nachvollziehbarkeit – etwa im Rahmen von ISO 27001 und mittelbar auch von Art. 32 GDPR.

Trusted Container Registries

Ein drittes Security-Guardrail konzentriert sich auf die Herkunft von Images. Im einfachsten Fall werden nur Images aus einer Handvoll vertrauenswürdiger Registries zugelassen:

• Die eigene Unternehmensregistry,
• ein zentral gemanagter Scan- und Signatur-Hub,
• ggf. definierte Partner-Registries.

Kyverno validiert dabei das Image-Feld der Container-Definition. Images aus unbekannten Quellen werden abgelehnt. Kombiniert mit einem ordentlichen Vulnerability-Management in der Registry steigt dadurch das Sicherheitsniveau im Cluster signifikant.

Reliability Guardrails: Ressourcenmanagement und Resilienz

Reliability-Guardrails zielen weniger auf Angriffe ab als auf Stabilität und Betriebsbereitschaft.

Verpflichtende Resource Requests

Ohne definierte CPU- und Speicher-Requests riskieren Sie:

• Überbuchung von Nodes,
• ungleich verteilte Last,
• unerwartete Performanceeinbrüche oder Out-of-Memory-Kills.

Ein Guardrail, das für alle Container minimale Resource Requests (und idealerweise Limits) erzwingt, ist hier zentral. Kyverno kann Deployments ablehnen, die keine Requests gesetzt haben, und damit die Grundlage für eine planbare Kapazitätsplanung schaffen – ein direktes Thema im Kontext von ISO 27001 (Kapazitätsplanung) und im Sinne von „Resilience“ in Art. 32 GDPR.

Mindestanzahl an Replikas und PodDisruptionBudgets

Für kritische Services in Produktion ist „Single Replica“ faktisch eine anti-pattern. Kyverno kann sicherstellen, dass:

• Deployments in produktiven Namespaces eine Mindestanzahl an Replikas aufweisen,
• für hochverfügbare Deployments PodDisruptionBudgets existieren oder zumindest empfohlen werden.

Solche Regeln helfen dabei, Verfügbarkeitsanforderungen aus Regulatorik und SLAs technisch abzusichern, anstatt sie nur auf Papier zu beschreiben.

Operational Guardrails: Storage, LoadBalancer & Co.

Operational-Guardrails adressieren Themen, die in Audits schnell zur Stolperfalle werden, obwohl sie selten im täglichen Fokus der Entwicklung stehen.

Typische Beispiele:

• Storage-Nutzung: Vorgabe, welche StorageClasses in welchen Umgebungen zulässig sind; Pflicht-Annotations für Backup-Relevanz von PersistentVolumeClaims. Das unterstützt Backup- und Desaster-Recovery-Anforderungen.
• LoadBalancer-Einsatz: Beschränkungen für externe LoadBalancer, um unkontrollierte Exponierung von Services ins Internet zu verhindern; zentrale Steuerung über Ingress-Controller statt direkte Service-Exponierung.
• Secrets-Management: Sicherstellen, dass Applikationen Secrets nicht mehr direkt im Manifest, sondern z. B. über eine Lösung wie den External Secrets Operator (ESO) beziehen. Kyverno kann prüfen, ob sensible Konfigurationen nur aus vertrauenswürdigen Quellen referenziert werden.

Diese Guardrails wirken oft „unsichtbar“, bis ein Audit oder ein Incident sie ins Rampenlicht rückt. Mit Policy as Code werden sie reproduzierbar, dokumentiert und nachvollziehbar.

---

Regulatorischer Kontext: GDPR Art. 32, NIS‑2 und BSI IT‑Grundschutz

Regulierung ist heute ein zentraler Rahmen für technische Entscheidungen – insbesondere bei kritischen Infrastrukturen, Finanzdienstleistern, Gesundheitswesen und dem öffentlichen Sektor. Kyverno ist kein „Compliance-Tool“ im engeren Sinn, aber ein sehr wirkungsvolles Werkzeug, um technische Anforderungen aus Normen und Gesetzen systematisch umzusetzen.

GDPR Art. 32: Sicherheit der Verarbeitung

Die Datenschutz-Grundverordnung gilt seit dem 25.05.2018 in allen EU-Mitgliedstaaten. Art. 32 fordert „geeignete technische und organisatorische Maßnahmen“ zur Gewährleistung eines angemessenen Schutzniveaus – insbesondere:

• Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme,
• die Fähigkeit, die Sicherheit regelmäßig zu überprüfen, zu bewerten und zu evaluieren.

Policy as Code mit Kyverno unterstützt diese Anforderungen gleich in mehreren Dimensionen:

• Technische Maßnahmen (z. B. Network Segmentation, Resource-Isolation) werden als wiederholbare, versionierte Policies umgesetzt.
• Die Wirksamkeit lässt sich anhand von Policy-Reports und Block-Statistiken objektiv bewerten.
• Regelmäßige Reviews und Anpassungen von Policies werden zum regulären Bestandteil des Change-Management-Prozesses.

Statt Sicherheitsanforderungen in Word-Dokumenten zu verwalten, werden sie so zu lebendigen, überprüfbaren Teilen Ihrer Plattform.

NIS‑2: Sicherheit bei Entwicklung und Betrieb kritischer Dienste

Die NIS‑2-Richtlinie der EU ist am 16.01.2023 in Kraft getreten; die Mitgliedstaaten müssen sie bis zum 17.10.2024 in nationales Recht umsetzen. Sie verschärft die Anforderungen an Unternehmen in kritischen Sektoren – unter anderem im Hinblick auf:

• Sicheres Design und sichere Entwicklung von Systemen,
• Vulnerability Handling und Patch-Management,
• Operational Security und Incident-Prevention.

Für Organisationen, die unter NIS‑2 fallen, bedeutet das: Sie müssen nachweisen, dass Sicherheit nicht nur auf Papier existiert, sondern in den Entwicklungs- und Deployment-Prozessen verankert ist.

Kyverno-basierte Guardrails sind dafür ein starker Baustein:

• Sie verankern Sicherheitsanforderungen direkt in der Kubernetes-Plattform.
• Sie sorgen dafür, dass unsichere Konfigurationen nicht unbemerkt in kritische Umgebungen gelangen.
• Sie liefern messbare Kennzahlen über Regelverletzungen, Blockierungen und Policy-Abdeckung.

In Kombination mit übergeordneten Governance-Strukturen – siehe unser Bereich Compliance – entsteht so eine belastbare Nachweisführung gegenüber Aufsichtsbehörden.

BSI IT‑Grundschutz: Admission Controller und Zugriffsschutz

Der BSI IT‑Grundschutz formuliert für Container- und Orchestrierungsumgebungen konkrete Empfehlungen, unter anderem:

• Zugriffsschutz auf Control-Plane-Funktionen,
• konsequente Nutzung von Admission Controllern,
• Zuweisung von Ressourcen über Namespaces und Policies.

Kyverno greift genau hier: Es erweitert den nativen Admission-Controller-Mechanismus von Kubernetes um eine flexible Policy-Schicht. Damit lassen sich BSI-Anforderungen wie:

• segmentierte Namespaces,
• verpflichtende NetworkPolicies,
• definierte Security-Kontexte und Rollen

nicht nur dokumentieren, sondern erzwingen – mit einem auditierbaren Trail von Policy-Definitionen und -Änderungen.

---

Praktisches Beispiel: Policy-basierte Deployment-Validierung

Wie sieht das in der Praxis aus? Ein realistisches Szenario aus vielen Organisationen:

Ausgangslage

Ihr Unternehmen betreibt mehrere produktive Kubernetes-Cluster. Verschiedene Teams deployen ihre Anwendungen eigenständig über CI/CD-Pipelines. Bisher existieren Sicherheitsrichtlinien vor allem in Form von Dokumenten:

• „Keine Root-Container in Produktion“
• „Keine :latest-Tags“
• „Jeder Namespace braucht eine NetworkPolicy“

In Audits oder Penetrationstests zeigt sich jedoch immer wieder: Einzelne Services weichen von diesen Vorgaben ab. Nicht aus Böswilligkeit, sondern aus Zeitdruck, Unwissen oder schlichter Vergesslichkeit.

Schritt 1: Policies als Code definieren

Die zentrale Plattform- oder Security-Einheit definiert gemeinsam mit den verantwortlichen Engineering-Teams eine erste Welle von Guardrails, etwa:

• Container dürfen nicht als Root laufen.
• Images müssen aus der Unternehmensregistry kommen und versioniert sein.
• Für produktive Namespaces müssen NetworkPolicies und Resource Requests gesetzt sein.

Diese Regeln werden als Kyverno-Policies in einem Git-Repository verwaltet, mit denselben Mechanismen wie Applikations- oder Infrastruktur-Code:

• Pull Requests,
• Code-Reviews,
• Versionshistorie und Change-Log.

Schritt 2: Einführung im Audit-Modus

Um Entwicklungsteams nicht zu überrollen, werden die neuen Policies zunächst im Audit-Modus ausgerollt:

• Deployments laufen durch, selbst wenn sie gegen Policies verstoßen.
• Verstöße werden als Policy Reports gesammelt und im Dashboard sichtbar gemacht.
• Das Compliance- oder Platform-Team gewinnt ein realistisches Bild, wo Handlungsbedarf besteht.

In dieser Phase geht es nicht darum, „Fehlende“ zu ertappen, sondern darum, eine gemeinsame Basis zu schaffen: Welche Regeln sind realistisch, wo braucht es Ausnahmen oder schrittweise Übergänge?

Schritt 3: Enforce-Modus für kritische Guardrails

Sobald die Organisation vorbereitet ist, werden ausgewählte Policies auf Enforce umgestellt, zum Beispiel:

• Verbot von Root-Containern in produktiven Namespaces,
• Blockierung von Images außerhalb vertrauenswürdiger Registries,
• Erzwingen von Resource Requests.

Ab diesem Zeitpunkt greift Kyverno direkt in den Deploy-Prozess ein: Wenn ein Team versucht, ein nicht-konformes Deployment auszurollen, wird der Request mit einer klaren, technischen Fehlermeldung abgelehnt. Wichtig ist hier die Qualität der Fehlermeldungen:

• Sie sollten den konkreten Verstoß benennen.
• Sie sollten – wo möglich – einen Lösungsvorschlag oder einen Link zur internen Dokumentation enthalten.

So werden Guardrails nicht als „Blockade“ wahrgenommen, sondern als Hilfestellung, sichere und konforme Deployments zu bauen.

Schritt 4: Integration in CI/CD und Reporting

Um Entwicklerinnen und Entwickler frühzeitig Feedback zu geben, wird Kyverno idealerweise nicht nur im Cluster, sondern auch indirekt in CI/CD sichtbar:

• Pipeline-Schritte, die Test-Deployments gegen einen Validierungs-Cluster fahren,
• Auswertung von Policy-Verstößen als Qualitätsmetriken,
• Dashboards, die Compliance-Status pro Team oder Applikation anzeigen.

Aus Sicht von Management und Compliance-Verantwortlichen entsteht damit eine durchgängige Kette:

• Richtlinien in Form von Kyverno Policies,
• technische Durchsetzung im Cluster,
• Reporting über Policy-Reports und Dashboards.

Genau diese Verbindung aus „Policy“ und „Proof of Effectiveness“ ist in vielen Regulierungen gefordert – von Art. 32 GDPR über NIS‑2 bis hin zum BSI IT‑Grundschutz.

---

Häufige Fragen

Wie viel Aufwand bedeutet die Einführung von Kyverno in einem bestehenden Cluster?

Der technische Einstieg ist vergleichsweise überschaubar: Kyverno wird wie andere Komponenten auch im Cluster installiert und registriert sich als Admission Controller. Der eigentliche Aufwand liegt in der konzeptionellen Arbeit:

• Welche Policies sind für Ihre Organisation wirklich relevant?
• Wie werden Ausnahmen gehandhabt?
• Wie binden Sie Teams in Design und Review der Regeln ein?

Bewährt hat sich ein iterativer Ansatz: Zunächst wenige, aber wirkungsvolle Guardrails im Audit-Modus etablieren, Transparenz schaffen und dann Schritt für Schritt auf Enforce umschalten. Mit vordefinierten Policy-Sets und Erfahrung aus anderen Umgebungen lässt sich dieser Prozess deutlich beschleunigen.

Wie passt Kyverno zu anderen Sicherheits- und Compliance-Tools?

Kyverno ersetzt keine Vulnerability-Scanner, SIEM-Systeme oder GRC-Plattformen. Es ergänzt sie:

• Scanner finden Schwachstellen in Images oder Laufzeitumgebungen.
• Kyverno stellt sicher, dass nur geprüfte Images aus vertrauenswürdigen Registries deployt werden.
• Ein zentrales Compliance- oder Governance-System dokumentiert Policies auf Management-Ebene.
• Kyverno bildet diese Policies auf technischer Ebene im Kubernetes-Cluster ab und liefert messbare Kennzahlen zur Einhaltung.

Damit wird Kyverno zu einem verbindenden Element zwischen organisatorischer Compliance-Ebene und technischer Realität.

Welche Rolle spielt ayedo bei Kyverno und Policy as Code?

ayedo nutzt Kyverno als fest integrierten Baustein der eigenen Plattform: Guardrails werden als Kyverno Policies implementiert, standardmäßig im Enforce-Modus, und über Dashboards transparent gemacht. Unternehmen profitieren so von:

• einem kuratierten Set bewährter Security-, Reliability- und Operational-Policies,
• einer integrierten Reporting-Schicht für Audits,
• Unterstützung bei der Anpassung und Erweiterung der Policies an eigene Anforderungen.

Statt bei Null zu starten, können Sie auf praxiserprobte Konfigurationen aufbauen und diese an Ihre Governance-Vorgaben und regulatorischen Rahmenbedingungen anpassen.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Kyverno zeigt sehr deutlich, dass regulatorische Anforderungen und moderne Cloud-Native-Entwicklung keine Gegensätze sind. Im Gegenteil: Wenn Security- und Betriebsrichtlinien als Code direkt in Ihre Kubernetes-Plattform integriert werden, entsteht ein verlässlicher Rahmen, in dem Teams schnell entwickeln und gleichzeitig nachweisbar compliant deployen können.

Für europäische Unternehmen, die sich den Anforderungen von GDPR, NIS‑2 und nationalen Standards wie dem BSI IT‑Grundschutz stellen müssen, ist das eine Chance: Statt Compliance als „Last“ zu sehen, wird sie zum Qualitätsmerkmal Ihrer digitalen Produkte und Services.

ayedo unterstützt Sie dabei auf mehreren Ebenen:

• Kyverno als integraler Bestandteil der Plattform: Guardrails sind nicht nur optionales Add-on, sondern Kernbestandteil der Delivery-Architektur. Security- und Reliability-Policies werden standardmäßig im Enforce-Modus bereitgestellt, können aber kontrolliert im Audit-Modus eingeführt werden.
• Vordefinierte Policy-Sets mit Compliance-Mapping: Die von ayedo bereitgestellten Kyverno Policies sind so gestaltet, dass sie sich klar Norm-Controls und regulatorischen Anforderungen zuordnen lassen. Das erleichtert die Argumentation gegenüber Audits und Aufsichtsbehörden.
• Integration in Ihre Toolchain: Von CI/CD-Pipelines über Monitoring bis hin zu Secrets-Management mit Lösungen wie dem External Secrets Operator (ESO) sorgt ayedo dafür, dass Policies durchgängig wirken und nicht an Systemgrenzen enden.
• Begleitung beim Policy Lifecycle: Design, Review, Rollout, Monitoring und kontinuierliche Verbesserung – ayedo bringt hier Erfahrung aus vielen Umgebungen mit und hilft Ihnen, eine für Ihr Unternehmen passende Policy-as-Code-Governance aufzubauen.

Wenn Sie Kyverno nicht nur als Tool, sondern als strategischen Baustein Ihrer Sicherheits- und Compliance-Architektur etablieren wollen, lohnt sich ein tieferer Blick in unsere Kyverno-basierte Guardrail-Umsetzung und deren Einbettung in Ihre Plattform-Strategie: Kyverno Policies