Kubernetes-Sicherheit: RBAC, Netzwerkrichtlinien und Pod-Sicherheit

Kubernetes orchestriert containerisierte Workloads in großem Maßstab, doch seine Komplexität schafft eine umfangreiche Angriffsfläche. Zu den wichtigen Komponenten, die abgesichert werden müssen, gehören: der API Server (die zentrale Control Plane – eine Kompromittierung ermöglicht die Kontrolle über den gesamten Cluster), etcd (die Datenbank für den Clusterstatus – sie speichert Secrets in Base64 und muss bei der Speicherung verschlüsselt werden), der kubelet (Node-Agent – eine nicht authentifizierte kubelet-API ermöglicht die beliebige Ausführung von Pods), die Container-Laufzeit (Docker/containerd) und die Netzwerkinfrastruktur, die alle Pods miteinander verbindet. Kandidaten für Security+ sollten verstehen, dass Fehlkonfigurationen in Kubernetes zu den häufigsten Cloud-Sicherheitsbefunden gehören.

Kubernetes-RBAC (Role-Based Access Control) steuert, welche Benutzer, Servicekonten und Prozesse welche Aktionen für welche API-Ressourcen ausführen dürfen. Das Modell umfasst vier Objekte: Role (Berechtigungen innerhalb eines Namespace), ClusterRole (clusterweite Berechtigungen), RoleBinding (weist einem Subjekt innerhalb eines Namespace eine Role zu) und ClusterRoleBinding (weist einem Subjekt clusterweit eine ClusterRole zu). Jeder kubectl-Befehl wird in einen API-Aufruf übersetzt, der anhand der RBAC-Regeln geprüft wird. Wenn RBAC nicht konfiguriert ist, kann jeder authentifizierte Benutzer (oder jedes Servicekonto) über Administratorrechte verfügen.

Jeder Pod in Kubernetes wird unter einem Servicekonto ausgeführt – einer Identität zur API-Authentifizierung. Standardmäßig verwenden Pods das default-Servicekonto ihres Namespace, das möglicherweise weitreichende Berechtigungen besitzt. Das Prinzip der geringsten Berechtigung erfordert, für jede Anwendung dedizierte Servicekonten mit ausschließlich den benötigten Berechtigungen zu erstellen. Außerdem verhindert die Einstellung automountServiceAccountToken: false für Pods, die keinen API-Zugriff benötigen, dass das Servicekonto-Token in das Dateisystem des Pods eingebunden wird, wo eine kompromittierte Anwendung es für API-Aufrufe verwenden könnte.

Standardmäßig können in Kubernetes alle Pods mit allen anderen Pods in jedem Namespace kommunizieren. Ein kompromittierter Pod kann sofort versuchen, Datenbanken, interne APIs und andere Microservices zu erreichen. Kubernetes-NetworkPolicy-Ressourcen definieren Regeln, die den Datenverkehr zwischen Pods anhand von Labels, Namespaces und Ports beschränken. Der empfohlene Ansatz ist eine Netzwerkpolicy nach dem Muster „standardmäßig alles verweigern“ in jedem Namespace, gefolgt von expliziten Erlaubnisregeln für erforderliche Kommunikationspfade. Beachten Sie, dass NetworkPolicy ein CNI-Plugin voraussetzt, das diese Funktion unterstützt (Calico, Cilium, Weave) – ein unverändertes Kubernetes ignoriert NetworkPolicy ohne ein kompatibles CNI.

Die Pod Security Standards (PSS), die in Kubernetes 1.23 eingeführt und in 1.25 stabil wurden, ersetzen die veraltete Pod Security Policy (PSP) durch drei integrierte Profile, die auf Namespace-Ebene durchgesetzt werden: Privileged (uneingeschränkt, für Systemkomponenten), Baseline (verhindert bekannte Rechteausweitungen wie privilegierte Container und den Zugriff auf das Hostnetzwerk) und Restricted (gehärtet, erfordert Nicht-Root-Benutzer, entfernt alle Capabilities und erzwingt schreibgeschützte Root-Dateisysteme). Namespaces werden mit Labels versehen, um eine Richtlinienebene durchzusetzen; Pods, die dagegen verstoßen, werden bei der Admission abgelehnt.

Kubernetes-Secrets speichern vertrauliche Daten wie Passwörter, Token und TLS-Zertifikate. Standardmäßig werden Secrets in etcd als Base64-codierte Werte gespeichert – nicht verschlüsselt. Jeder, der etcd lesen kann oder über ausreichende RBAC-Berechtigungen verfügt, kann sie problemlos dekodieren. Zu den Best Practices gehören: die Aktivierung der Verschlüsselung ruhender Daten in etcd mit AES-GCM und einem in einem KMS gespeicherten Schlüssel (AWS KMS, GCP KMS), die Integration eines externen Secrets-Managers wie HashiCorp Vault oder AWS Secrets Manager über den Secrets Store CSI Driver sowie die Beschränkung des Secret-Zugriffs über RBAC, sodass nur die benötigten Servicekonten sie lesen können.

Admission Controller sind Plugins im Kubernetes-API-Server, die API-Anfragen nach der Authentifizierung und Autorisierung, aber vor der Speicherung des Objekts abfangen. Dadurch können sie Anfragen validieren, verändern oder ablehnen. Zu den sicherheitsrelevanten Admission Controllern gehören: PodSecurity (setzt Pod Security Standards durch), ImagePolicyWebhook (ermöglicht die externe Prüfung der Image-Signierung), AlwaysPullImages (erzwingt das erneute Abrufen von Images, um die Verwendung lokal zwischengespeicherter schädlicher Images zu verhindern) und OPA/Gatekeeper (Open Policy Agent – die flexibelste Lösung, mit der sich benutzerdefinierte, in der Sprache Rego formulierte Policies zur Durchsetzung beliebiger organisatorischer Sicherheitsregeln erstellen lassen).

Die Härtung der Kubernetes-Control-Plane-Komponenten ist entscheidend: Der API-Server sollte mit --anonymous-auth=false konfiguriert werden, um nicht authentifizierten Zugriff zu deaktivieren, mit --audit-log-path, um sämtliche API-Aktivitäten zu erfassen, sowie mit TLS für alle Verbindungen. Der kubelet sollte --authorization-mode=Webhook (nicht AlwaysAllow) verwenden und die anonyme Authentifizierung deaktivieren. etcd sollte TLS-Verschlüsselung für Peer- und Client-Verbindungen, einen beschränkten Netzwerkzugriff (nur durch den API-Server erreichbar) und eine Verschlüsselung der ruhenden Daten verwenden. Der CIS Kubernetes Benchmark bietet eine umfassende Checkliste für die Einstellungen aller Komponenten.

Kubernetes-Namespaces ermöglichen eine logische Trennung von Ressourcen, sind für sich genommen jedoch keine starke Sicherheitsgrenze – sie sorgen in erster Linie für organisatorische Isolation. Für eine echte Mandantenisolation (z. B. bei Workloads verschiedener Kunden) sind zusätzliche Kontrollen erforderlich: Netzwerkpolicies zum Blockieren von Datenverkehr zwischen Namespaces, Ressourcenquoten zur Verhinderung eines DoS durch übermäßige Ressourcennutzung einzelner Mandanten, separate Node-Pools für stark isolierte Mandanten oder dedizierte Cluster pro Mandant. Viele Organisationen verwenden Hierarchical Namespaces oder kommerzielle Lösungen wie vCluster, um die Multi-Tenancy innerhalb eines einzelnen Clusters stärker abzusichern.

Die Audit-Protokollierung von Kubernetes erfasst jede API-Anfrage: wer sie gestellt hat, von wo aus, welche Aktion angefordert wurde und auf welche Ressource sie abzielte. Audit-Protokolle sind für die forensische Untersuchung nach einem Sicherheitsvorfall und zur Erkennung anomalen Verhaltens wie ungewöhnlicher RoleBindings, des Zugriffs auf Secrets oder von Exec-Befehlen in Produktions-Pods unerlässlich. Audit-Protokolle sollten an ein zentrales SIEM gestreamt werden. Falco ermöglicht die Laufzeitüberwachung des Containerverhaltens, während cloudverwaltete Kubernetes-Dienste (EKS, GKE, AKS) eine native Integration von Audit-Protokollen in ihre jeweiligen Logging-Plattformen bieten.

Die Sicherheit der Software-Lieferkette für Kubernetes stellt sicher, dass nur vertrauenswürdige und verifizierte Images die Produktion erreichen. Die Empfehlungen der CNCF zur Supply Chain Security umfassen: das Überprüfen von Image-Signaturen mit Cosign vor der Bereitstellung (durchgesetzt über Admission Controller), das Erstellen und Überprüfen von SBOMs (Software Bills of Materials) für alle Container-Images, um die Herkunft der Komponenten nachzuverfolgen, das Fixieren von Images auf Digests (myimage@sha256:abc123) statt auf veränderliche Tags sowie das Scannen aller Helm-Charts von Drittanbietern auf Fehlkonfigurationen und Sicherheitslücken vor der Bereitstellung.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Kubernetes-RBAC steuert den API-Zugriff über Roles, ClusterRoles und Bindings – wenden Sie auf Service-Accounts stets das Prinzip der geringsten Berechtigungen an. NetworkPolicy-Konfigurationen mit standardmäßig verweigertem Zugriff verhindern die laterale Bewegung zwischen Pods und Namespaces, und Pod Security Standards erzwingen die Härtung von Containern auf Namespace-Ebene, indem sie privilegierte Container, den Zugriff auf das Hostnetzwerk und die Ausführung als Root blockieren. Als Nächstes behandeln wir die Sicherheit serverloser Architekturen und Angriffsfächen auf Funktionsebene.