Kubernetes hat die Art verändert, wie Anwendungen gebaut und ausgeliefert werden. Statt eines großen Releases im Quartal gehen kleine Änderungen mehrmals am Tag in Produktion, automatisiert über Pipelines. Das ist schnell, stellt aber eine alte Frage neu: Wie lässt sich nachweisen, dass dabei alle Sicherheits- und Compliance-Vorgaben eingehalten werden, wenn kein Mensch mehr jede Änderung einzeln freigibt?

Wir betreiben Kubernetes-Cluster für Unternehmen, die genau diese Frage beantworten müssen, darunter viele aus regulierten Branchen. Unsere Erfahrung: Die Antwort liegt nicht in mehr Kontrolle von Hand, sondern darin, die Regeln selbst in den Cluster zu schreiben. Was wir dabei übernehmen, beschreibt unsere Seite zu Managed Kubernetes. Dieser Beitrag zeigt, wie sich Vorgaben durchsetzen lassen und welche Maßnahmen Anwendungen im Cluster schützen.

Warum ist Kubernetes-Sicherheit eine Compliance-Frage?

Weil Prüfer heute nicht nur wissen wollen, ob eine Umgebung sicher ist, sondern wie das belegt wird. Unternehmen unter DORA oder NIS2 müssen zeigen, dass ihre Änderungsprozesse, Zugriffsrechte und Sicherheitsmaßnahmen geregelt sind und wirken. In einer Kubernetes-Umgebung mit vielen automatisierten Deployments lässt sich das nicht mehr über Freigaben im Ticket allein abbilden.

Die Lösung ist, Sicherheitsvorgaben früh im Entwicklungsprozess zu verankern, im Fachjargon „Shift left“. Werden die Regeln erst am Ende eines Release-Zyklus geprüft, bleiben Verstöße lange unentdeckt und müssen aufwendig nachgearbeitet werden. Werden sie dagegen schon in der Pipeline und beim Deployment geprüft, kommt ein Verstoß gar nicht erst in Produktion. Jede abgelehnte Änderung ist zugleich ein Nachweis, dass die Regel wirkt.

Wie lassen sich Compliance-Vorgaben in Kubernetes durchsetzen?

Mit Policy as Code. Die Regeln werden nicht in einem Dokument beschrieben, sondern als Code hinterlegt, den Kubernetes bei jeder Änderung automatisch prüft. Dafür gibt es zwei Ebenen.

Die erste bringt Kubernetes selbst mit: Die Pod Security Standards legen in drei Stufen fest, was ein Pod darf, von uneingeschränkt bis streng begrenzt. Ein eingebauter Kontrollmechanismus, die Pod Security Admission, setzt diese Stufen je Namespace durch. Die früheren Pod Security Policies, die ältere Anleitungen noch beschreiben, wurden mit Version 1.25 aus Kubernetes entfernt.

Die zweite Ebene sind Werkzeuge für eigene Regeln, allen voran der Open Policy Agent. Er prüft jedes neue oder geänderte Objekt, bevor Kubernetes es annimmt. Was gegen eine Regel verstößt, lehnt er ab. Ein einfaches Beispiel: Jede Anwendung muss ein Label tragen, das ihre Umgebung angibt, also Test, Staging oder Produktion. Fehlt es, wird das Deployment mit einer verständlichen Meldung gestoppt. Dieselben Regeln lassen sich schon in der Pipeline gegen Manifeste und Infrastruktur-Code prüfen, lange bevor etwas den Cluster erreicht. Wie das technisch aufgebaut ist, beschreibt die Dokumentation des Open Policy Agent.

Welche Maßnahmen schützen Anwendungen im Cluster?

Kubernetes ist so sicher wie seine Konfiguration. Sieben Maßnahmen haben sich in unseren Projekten bewährt:

  1. Root-Rechte vermeiden: Container sollten nur in begründeten Ausnahmen mit vollen Rechten laufen. Wird ein solcher Container kompromittiert, kann der Angreifer im schlimmsten Fall den ganzen Cluster übernehmen. Die strenge Stufe der Pod Security Standards verhindert das standardmäßig.
  2. Versionen aktuell halten: Das Kubernetes-Projekt pflegt jeweils die drei neuesten Versionen mit Sicherheitsupdates, jede rund ein Jahr lang. Wer Upgrades nicht plant, landet schnell auf einer Version ohne Patches.
  3. Rechte nach dem Prinzip der geringsten Berechtigung vergeben: Die rollenbasierte Zugriffskontrolle RBAC regelt, was Personen und was Dienstkonten im Cluster dürfen. Beide Fragen gehören vorab ins Sicherheitskonzept, denn in automatisierten Umgebungen handeln oft Programme statt Menschen.
  4. Netzwerkverkehr begrenzen: Network Policies legen fest, welche Pods miteinander sprechen dürfen. Ohne sie kann jeder Pod jeden anderen erreichen. Ein kompromittierter Dienst wird so zum Sprungbrett.
  5. Richtlinien automatisch prüfen: Policy as Code wie oben beschrieben, ergänzt um Tests in einer Staging-Umgebung und das Vier-Augen-Prinzip bei Codeänderungen.
  6. Ressourcen begrenzen: Anforderungen und Grenzen für Prozessor und Arbeitsspeicher je Container verhindern, dass eine fehlerhafte Anwendung alle Ressourcen eines Knotens belegt und andere Pods mit in den Ausfall zieht.
  7. Regelmäßig scannen: Container-Images und Konfigurationen auf bekannte Schwachstellen prüfen, vor dem Deployment und im laufenden Betrieb. Wie man die Funde priorisiert, beschreibt unser Beitrag zum Vulnerability Management.

Wer ist bei Managed Kubernetes wofür zuständig?

Die Plattform liegt beim Dienstleister, die Anwendung beim Kunden. Bei unserem Managed Kubernetes provisionieren, aktualisieren und überwachen wir die Cluster. Jeder Cluster bringt RBAC, Network Policies, Pod Security Standards und Image Scanning bereits mit. Auf unserer Private Cloud sind die Cluster dediziert, kein Kunde teilt sich Nodes mit einem anderen. Der Kunde verantwortet seine Container-Images, seine Deployments und die Rechte innerhalb seiner Anwendungen, wenn er diese Aufgaben nicht ebenfalls an uns übergibt.

Für die Compliance zählt neben der Technik der Nachweis. Prüfer fragen nach Zertifikaten und Prüfberichten für die Plattform, auf der die Cluster laufen. Was ein Prüfbericht nach IDW PS 951 dabei leistet und was er nicht abdeckt, zeigt unser Beitrag zur IKS-Prüfung beim IT-Dienstleister.

Fazit: Regeln in den Cluster schreiben, nicht ins Wiki

Kubernetes macht Sicherheit und Compliance nicht schwerer, aber anders. Statt jede Änderung von Hand freizugeben, werden die Regeln als Code hinterlegt und bei jedem Deployment automatisch geprüft. Pod Security Standards, Policy as Code, klare Rechte, begrenzter Netzwerkverkehr, aktuelle Versionen und regelmäßige Scans bilden zusammen eine Umgebung, die sich auch gegenüber Prüfern belegen lässt. Wie wir Cluster mit diesen Vorgaben betreiben, auf unserer Private Cloud oder auf Azure, AWS und Google Cloud, zeigt die Seite zu Managed Kubernetes.