Kubernetes-Härtung: Eine praxistaugliche Baseline

Kubernetes ist zur Standard-Steuerungsebene für moderne Workloads geworden, und mit dieser Allgegenwart ist es auch zu einem lohnenden Ziel geworden. Ein Cluster ist kein einzelnes System, sondern eine verteilte Ansammlung von APIs, Controllern, Netzwerkpfaden und Identitäten, und jede dieser Schichten lässt sich so fehlkonfigurieren, dass der Wirkungsradius eines einzigen kompromittierten Containers still und leise wächst. Dieser Artikel beschreibt eine praxistaugliche Härtungs-Baseline für Verteidiger und Plattform-Ingenieure, die Cluster im Produktivbetrieb verantworten. Der Rahmen ist durchgehend verstehen, um zu verteidigen: Wir beschreiben, wie Schwachstellen entstehen, welche Telemetrie Missbrauch sichtbar macht und welche Kontrollen die Angriffsfläche verkleinern, ohne die Plattform unbedienbar zu machen.

Warum eine Härtungs-Baseline wichtig ist

Standardinstallationen von Kubernetes optimieren auf Funktionalität und Entwicklungsgeschwindigkeit, nicht auf minimale Rechte. Ab Werk finden Sie womöglich großzügig eingehängte Service-Account-Tokens, als root laufende Container, keinerlei Netzwerkrichtlinien und einen API-Server, der von mehr Orten erreichbar ist als beabsichtigt. Das ist kein Fehler, sondern ein Ausgangspunkt, der voraussetzt, dass Sie eigene Leitplanken setzen. Eine Baseline liefert eine schriftliche, prüfbare Definition der Mindestposition, die jeder Cluster erfüllen muss, sodass Sicherheit eine Eigenschaft der Plattform wird und nicht etwas, das jedes Team neu erfindet. Ohne sie ist Drift unvermeidlich und Audits werden zur Archäologie.

Eine gute Baseline ist geschichtet. Sie umfasst die Steuerungsebene, die Knoten, die Workloads, das Netzwerk, die Lieferkette und die Identitäten, die alles verbinden. Sie wird zudem durch Mechanik erzwungen statt durch guten Willen: Admission Control, Policy-as-Code und kontinuierliches Konfigurations-Scanning machen die Baseline zu etwas, das der Cluster zu verletzen sich weigert. Ebenso wichtig ist, dass die Baseline versioniert und im Repository nachvollziehbar abgelegt ist, damit jede Änderung überprüfbar bleibt und ein Reviewer nachvollziehen kann, warum eine bestimmte Regel gilt. So wird Sicherheit zu einer geteilten, überprüfbaren Vereinbarung statt zu implizitem Wissen einzelner Personen.

Steuerungsebene und API-Server

Der API-Server ist die Eingangstür zu allem. Anonyme Authentifizierung sollte deaktiviert sein, und jede Anfrage sollte eine überprüfbare Identität mit kurzlebigen Anmeldedaten tragen. Das Audit-Log des kube-apiserver ist Ihre wertvollste Wahrheitsquelle; aktivieren Sie es mit einer Richtlinie, die Metadaten für Lesezugriffe und vollständige Anfrage-Bodys für Schreibzugriffe auf sensible Ressourcen wie Secrets, Roles und RoleBindings erfasst. Speichern Sie diese Logs außerhalb des Clusters, damit ein eingedrungener Angreifer seine eigenen Spuren nicht kürzen kann. Etcd, das den gesamten Clusterzustand inklusive Secrets hält, muss verschlüsselt gespeichert und nur vom API-Server über gegenseitiges TLS erreichbar sein.

Beschränken Sie auf Netzwerkebene, wer den API-Endpunkt erreichen darf. Eine verwaltete Steuerungsebene mit privatem Endpunkt und einer Allowlist autorisierter Netze entfernt einen großen Teil des dem Internet zugewandten Risikos. Zertifikate sollten automatisch rotieren, und die Admin-Kubeconfig des Clusters sollte wie ein Kronjuwel behandelt werden und nicht wie eine Datei, die auf Laptops liegt.

Workload-Identität und RBAC

Rollenbasierte Zugriffskontrolle ist der Ort, an dem die meisten realen Cluster Rechte verlieren. Die beiden Anti-Muster, nach denen Sie fahnden sollten, sind Platzhalter-Verben oder -Ressourcen in einer Rolle sowie Bindungen an die eingebaute Rolle cluster-admin für Menschen oder Service Accounts, die sie nicht wirklich brauchen. Gewähren Sie den engsten Satz an Verben auf dem engsten Satz an Ressourcen im engsten Geltungsbereich und bevorzugen Sie namensraumgebundene Rollen gegenüber clusterweiten. Jeder Service Account, der Pods erstellen, Secrets lesen oder RoleBindings ändern kann, ist faktisch ein Pfad zu weiterreichender Kontrolle, denn diese Verben lassen sich zu Eskalation verketten.

Deaktivieren Sie das automatische Einhängen von Service-Account-Tokens standardmäßig und aktivieren Sie es nur für Workloads, die die API tatsächlich aufrufen. Wo eine Workload Cloud-Berechtigungen benötigt, nutzen Sie die Workload-Identity-Föderation der Plattform, damit Pods kurzlebige, zielgruppengebundene Tokens erhalten statt langlebiger statischer Schlüssel in Secrets. Überprüfen Sie RBAC fortlaufend; eine Bindung, die letztes Quartal sinnvoll war, kann nach einer Team-Umstrukturierung gefährlich sein.

Härtung der Workloads selbst

Auf Pod-Ebene ist das Ziel, aus einem kompromittierten Container eine Sackgasse statt einer Startrampe zu machen. Laufen Sie als Nicht-root-Benutzer mit schreibgeschütztem Wurzeldateisystem, verwerfen Sie alle Linux-Capabilities und fügen Sie nur das strikt Nötige hinzu, und verbieten Sie Rechteausweitung mit allowPrivilegeEscalation: false. Privilegierte Container, das Teilen von Host-Namensräumen (hostPID, hostNetwork, hostIPC) und Host-Pfad-Einhängungen sind die Funktionen, die Angreifer am meisten begehren, weil jede die Grenze zwischen Container und Knoten aufweicht. Behandeln Sie sie als Ausnahmen mit ausdrücklicher Prüfung, nicht als Standard.

Wenden Sie ein Seccomp-Profil wie RuntimeDefault an, um die Systemaufrufe eines Containers einzuschränken, und legen Sie, wo Ihre Workloads es vertragen, AppArmor oder SELinux darüber. Die Pod Security Standards geben Ihnen drei benannte Stufen — privileged, baseline und restricted — und der eingebaute Pod-Security-Admission-Controller kann die Stufe restricted je Namensraum erzwingen. Für reichere Regeln erlaubt eine Policy-Engine wie Kyverno oder eine OPA/Gatekeeper-Installation, organisationsspezifische Vorgaben als Code auszudrücken und durchzusetzen.

Netzwerksegmentierung

Standardmäßig kann jeder Pod mit jedem anderen sprechen, was bedeutet, dass ein einziger Brückenkopf die gesamte Ost-West-Fläche sieht. Eine standardmäßig ablehnende NetworkPolicy je Namensraum, gefolgt von expliziten Erlaubnisregeln für die Flüsse, die jede Anwendung wirklich benötigt, ist eine der wirkungsvollsten Kontrollen. Sie verwandelt Seitwärtsbewegung von einem trivialen Sprung in eine Aktivität, die eine erzwungene Grenze überqueren muss, und macht auffällige Verbindungen sichtbar. Für stärkere Garantien kann ein Service Mesh gegenseitiges TLS zwischen Diensten und identitätsbewusste Autorisierung ergänzen, sodass eine gestohlene Netzwerkposition nicht dasselbe ist wie eine gestohlene Identität.

Vergessen Sie den ausgehenden Verkehr nicht. Zu begrenzen, was Pods nach außen erreichen dürfen, dämmt Datenabfluss ein und stumpft Schadsoftware ab, die nach Hause zu einem Command-and-Control-Host telefoniert. Kombinieren Sie Netzwerkrichtlinien mit DNS- und Egress-Protokollierung, damit unerwartete ausgehende Ziele zu erkennbaren Ereignissen werden. Ein häufig übersehener Sonderfall ist der Zugriff auf den Cloud-Metadaten-Endpunkt: Beschränken Sie ihn strikt, denn ein Angreifer, der ihn aus einem Pod erreicht, kann sich unter Umständen Cloud-Anmeldedaten beschaffen und so aus dem Cluster in das umgebende Konto ausbrechen.

Erkennung: Signale, die Missbrauch verraten

Härtung verkleinert die Angriffsfläche; Erkennung sagt Ihnen, wann jemand das Verbleibende abtastet. Das reichste Signal ist das API-Audit-Log. Achten Sie auf Anfragen, Secrets über Namensräume hinweg aufzuzählen, auf das Erstellen oder Ändern von ClusterRoleBinding-Objekten, auf exec oder attach in laufende Pods sowie auf Pods, die mit privilegierten oder Host-Namensraum-Einstellungen gestartet werden. Ein plötzlicher Schwall von 403 Forbidden-Antworten von einem einzelnen Service Account bedeutet oft, dass Anmeldedaten gestohlen wurden und gegen Ressourcen getestet werden, die sie nie berühren sollten.

Zur Laufzeit kann ein Verhaltenssensor wie Falco oder ein EDR-Agent mit Container-Bewusstsein eine in einem Container gestartete Shell melden, einen unerwarteten Prozess, der /etc/shadow liest, einen Schreibzugriff auf einen normalerweise schreibgeschützten Pfad oder eine ausgehende Verbindung zu einer verdächtigen Adresse. Korrelieren Sie Cluster-Ereignisse mit Knoten- und Cloud-Anbieter-Logs; ein Angreifer, der zum Knoten ausbricht oder zum Cloud-Metadaten-Endpunkt schwenkt, hinterlässt an mehr als einer Stelle Spuren, und die Korrelation macht aus isoliertem Rauschen eine klare Geschichte.

Häufige Fallstricke

Teams liefern häufig eine starke Richtlinie in einem Staging-Cluster und gewähren dann in der Produktion breite Ausnahmen, weil eine Frist drohte, und die Ausnahme wird nie erneut geprüft. Ein weiterer wiederkehrender Fehler ist, Pod-Sicherheit zu erzwingen und zugleich den API-Server von überall erreichbar zu lassen, sodass die stärkste Mauer kein Tor hat. Zu breite Image-Pull-Secrets, Secrets als Umgebungsvariablen, wo sie in Logs und Absturzabbildern auftauchen, und Cluster, die nie Anmeldedaten rotieren, sind häufige Lücken. Und das Audit-Log abzuschalten, weil es laut ist, tauscht Ihr bestes forensisches Werkzeug gegen etwas weniger Speicher — ein Handel, den Sie im Ernstfall bereuen.

Eine praktische Checkliste

Nutzen Sie dies als Ausgangs-Baseline und passen Sie es an Ihr Risiko an. Steuerungsebene: anonyme Auth aus, Audit-Logging an und außerhalb des Clusters gespeichert, etcd verschlüsselt, privater API-Endpunkt mit Netz-Allowlist. Identität: kein dauerhaftes cluster-admin, kein Platzhalter-RBAC, Token-Automounting standardmäßig aus, Workload-Identity für Cloud-Zugriff. Workloads: nicht-root, schreibgeschütztes Wurzeldateisystem, Capabilities verworfen, keine Rechteausweitung, seccomp RuntimeDefault, Pod Security Admission restricted, keine Host-Namensräume ohne Prüfung. Netzwerk: standardmäßig ablehnender Ein- und Ausgang je Namensraum, explizite Erlaubnisregeln, Mesh-mTLS wo machbar. Lieferkette: signierte Images, Admission-Verifikation, Schwachstellen-Scanning als Tor. Erkennung: Audit-Log-Alarme, Laufzeit-Verhaltenssensor, Log-Aufbewahrung länger als die Verweildauer.

FAQ: Reicht Pod Security Admission allein?

Es ist eine starke, eingebaute Grundlage zur Durchsetzung des restricted-Profils, und jeder Cluster sollte es nutzen. Doch es ist bewusst auf einen festen Satz von Pod-Kontrollen begrenzt. Für organisationsspezifische Regeln — geforderte Labels, erlaubte Registries, Image-Signaturprüfungen oder an Richtlinien gebundene Ressourcenkontingente — wollen Sie daneben eine allgemeine Policy-Engine wie Kyverno oder Gatekeeper. Betrachten Sie Pod Security Admission als den Boden und die Policy-Engine als die Wände darauf.

FAQ: Wie härte ich, ohne Entwickler zu blockieren?

Beginnen Sie in einem Audit- oder Warnmodus, damit Teams sehen, was blockiert würde, bevor tatsächlich etwas bricht, und veröffentlichen Sie die Baseline mit klarer Behebungsanleitung. Bieten Sie goldene Pfade — gehärtete Basis-Images, fertige Ausnahmeprozesse und Vorlagen, die die Regeln bereits erfüllen — damit die sichere Option auch die einfache ist. Durchsetzung gelingt reibungslos, wenn das Plattformteam Reibung beseitigt, statt bloß nein zu sagen.

Fazit

Eine Kubernetes-Härtungs-Baseline ist kein einmaliges Projekt, sondern ein lebendiger Vertrag zwischen Sicherheit und den Teams, die auf der Plattform ausliefern. Sperren Sie die Steuerungsebene ab, beschränken Sie Identität mit least-privilege RBAC und Workload-Identity, machen Sie kompromittierte Container zu Sackgassen, segmentieren Sie das Netzwerk standardmäßig, verifizieren Sie Ihre Lieferkette und instrumentieren Sie alles, damit Missbrauch sichtbar wird. Erzwingen Sie es mit Admission Control und Policy-as-Code, damit die Position nicht still driftet. Gut gemacht, ist Härtung für die Menschen, die auf dem Cluster bauen, unsichtbar und gegen die, die einbrechen wollen, entscheidend.