Viele Unternehmen setzen Kubernetes als zentrale Plattform ein und betreiben darauf geschäftskritische Anwendungen sowie sensible Daten. Entsprechend hoch sind die Anforderungen an die Sicherheit der Umgebung. Kubernetes-Hardening verfolgt mehrere Ziele: Es soll Angriffe abwehren, Sicherheitslücken reduzieren, sensible Informationen schützen, Compliancevorgaben erfüllen, Fehlkonfigurationen verhindern und sowohl externe als auch interne Bedrohungen minimieren. Nicht zuletzt geht es darum, die Verfügbarkeit der Plattform sicherzustellen und dauerhaft Vertrauen in die eigene Infrastruktur zu bewahren.

Ein wirksames Hardening setzt nicht an einer einzelnen Stelle an, sondern betrachtet den Cluster ganzheitlich. In der Praxis lassen sich die Maßnahmen in mehrere Themenbereiche gliedern:

- Zugriffskontrolle und Authentifizierung

- Netzwerksicherheit

- Container-Sicherheit

- Cluster- und Komponentenkonfiguration

- Secrets-Management

- Überwachung und Logging

Wir beleuchten diese Bereiche im Detail und zeigen konkrete Ansätze, Werkzeuge und Best Practices, mit denen sich Kubernetes-Umgebungen systematisch härten lassen.

Zugriffskontrolle und Authentifizierung

Wie bei allen verteilten Systemen bildet auch in Kubernetes eine saubere Zugriffskontrolle die Grundlage für Sicherheit. Nur wenn klar geregelt ist, wer sich authentifizieren darf und welche Aktionen erlaubt sind, lassen sich unbefugte Zugriffe und potenzielle Angriffe zuverlässig verhindern. Kubernetes bringt dafür mehrere Authentifizierungsmechanismen mit. Die interne Kommunikation innerhalb des Clusters, etwa zwischen Kubelet und API-Server, erfolgt über X.509-Zertifikate. Der API-Server prüft diese Zertifikate bei jeder Verbindung und stellt so sicher, dass nur bekannte und autorisierte Komponenten miteinander kommunizieren.

Für Workloads nutzt Kubernetes Service Accounts. Pods authentifizieren sich gegenüber dem API-Server über Service-Account-Tokens. Seit Kubernetes Version 1.24 hat sich die Sicherheit in diesem Bereich deutlich verbessert: Tokens entstehen nicht mehr statisch, sondern werden über das Token-API dynamisch erzeugt und sind zeitlich begrenzt gültig. Gibt ein Pod keinen Service Account an, verwendet Kubernetes automatisch den Default-Service-Account des jeweiligen Namespace. Dieser besitzt standardmäßig keine oder nur sehr eingeschränkte Rechte. Benötigt ein Pod Zugriff auf das Kubernetes-API, sollten Sie deshalb immer einen dedizierten Service Account anlegen, ihn gezielt berechtigen und explizit dem Pod zuweisen. Das Token rotiert Kubernetes anschließend automatisch.

Weniger empfehlenswert sind statische Bearer Tokens oder fest hinterlegte Tokens. Diese Verfahren eignen sich höchstens für sehr spezielle Szenarien und bergen erhebliche Sicherheitsrisiken, da kompromittierte Tokens lange gültig bleiben können.

In produktiven Umgebungen setzen die meisten Kubernetes-Distributionen inzwischen auf OpenID Connect (OIDC). Damit integrieren sie Kubernetes in bestehende Identity-Provider wie Microsoft Entra ID in der Cloud oder Keycloak im eigenen Rechenzentrum. OIDC ermöglicht Single Sign-On, zentrale Benutzerverwaltung und die Nutzung bestehender Sicherheitsmechanismen wie Multifaktor-Authentifizierung. Als Best Practice gilt: Nutzen Sie ausschließlich starke Authentifizierungsverfahren wie OIDC oder Zertifikate und deaktivieren Sie anonymen Zugriff konsequent.

Auf der Ebene der Autorisierung greifen in Kubernetes Rollen (Roles) und Cluster-Rollen (ClusterRoles). Auch hier folgt die Konfiguration dem Prinzip der minimalen Rechtevergabe. Benutzer und Service Accounts erhalten nur genau die Berechtigungen, die sie für ihre Aufgaben benötigen. Das folgende Beispiel zeigt eine einfache Konfiguration, mit der der Benutzer "charlie" Leserechte auf Pods im Namespace "it-admin" erhält:

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

namespace: it-admin

name: pod-reader

rules:

- apiGroups: [""]

resources: ["pods"]

verbs: ["get", "list"]

---

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

name: read-pods

namespace: it-admin

subjects:

- kind: User

name: charlie

apiGroup: rbac.authorization.k8s.io

roleRef:

kind: Role

name: pod-reader

apiGroup: rbac.authorization.k8s.io

Neben der eigentlichen Zugriffskontrolle sollten Sie auch das Audit-Logging aktivieren. Kubernetes kann sämtliche API-Zugriffe protokollieren und ermöglicht so die nachträgliche Analyse verdächtiger oder unautorisierter Aktionen. Ergänzend unterstützen Werkzeuge wie kube-bench bei der Überprüfung der Konformität mit den CIS-Benchmarks für Authentifizierung und RBAC. Policy-Engines wie Open Policy Agent (OPA) helfen dabei, RBAC-Regeln konsistent durchzusetzen und Fehlkonfigurationen frühzeitig zu verhindern.

Netzwerksicherheit über Policys

Die Netzwerksicherheit zählt zu den zentralen Bausteinen beim Hardening von Kubernetes-Clustern. Pods, Services und externe Systeme kommunizieren kontinuierlich miteinander und schaffen dadurch eine große Angriffsfläche. Ohne gezielte Einschränkungen kann sich ein Angreifer im Erfolgsfall schnell lateral im Cluster bewegen.

Eine der wichtigsten Maßnahmen sind Network Policys. Mit ihnen steuern Sie präzise, welcher Datenverkehr zwischen Pods und Namespaces erlaubt ist. Network Policys arbeiten auf Basis von Labels, Namespaces oder IP-Adressen und folgen einem expliziten Allow-Ansatz: Alles, was Sie nicht erlauben, bleibt automatisch blockiert. Dadurch lassen sich Anwendungen logisch voneinander trennen und Angriffswege deutlich einschränken.

Das folgende Beispiel zeigt eine einfache Network Policy. Sie erlaubt ausschließlich eingehende Verbindungen von Pods mit dem Label "app=frontend" zu Pods mit dem Label "app=web" auf TCP-Port 80:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: allow-specific

namespace: default

spec:

podSelector:

matchLabels:

app: web

ingress:

- from:

- podSelector:

matchLabels:

app: frontend

ports:

- protocol: TCP

port: 80

Mit dieser Regel verhindern Sie, dass andere Pods im Namespace oder im gesamten Cluster unkontrolliert auf den Web-Service zugreifen können. Das Bild zeigt exemplarisch den Network Policy Editor von Isovalent, mit dem sich solche Regeln grafisch darstellen, analysieren und bearbeiten lassen.

 

 

Über reine Zugriffsbeschränkungen hinaus spielt auch Verschlüsselung eine zentrale Rolle. Idealerweise verschlüsseln Sie jede Kommunikation – sowohl innerhalb des Clusters als auch nach außen. Die interne Kommunikation zwischen API-Server, kubelet und weiteren Kernkomponenten nutzt standardmäßig TLS. Bei selbst installierten Erweiterungen wie Ingress-Controllern, Gateway-Controllern oder Zusatzdiensten müssen Sie die Absicherung jedoch aktiv konfigurieren.

Besondere Aufmerksamkeit verdient der Kubernetes-API-Server. In vielen Managed-Kubernetes-Angeboten ist er standardmäßig öffentlich erreichbar. Sie sollten den Zugriff deshalb auf interne Netzwerke, VPNs oder explizit autorisierte IP-Bereiche beschränken. So reduzieren Sie die Angriffsfläche erheblich.

Für die Umsetzung moderner Netzwerk-Sicherheitskonzepte stehen zahlreiche Werkzeuge zur Verfügung:

- Calico bietet Network Policys, Netzwerksegmentierung und erweiterte Sicherheitsfunktionen. In Kombination mit dem Isovalent Network Policy Editor lassen sich Regeln übersichtlich verwalten.

- Cilium ist ein Open-Source-Projekt für cloudnative Netzwerke, Observability und Security. Es basiert auf eBPF und ermöglicht sehr feingranulare Sicherheitsregeln.

- Service Meshes wie etwa Istio oder Linkerd ergänzen klassische Network Policys um Layer-7-Funktionen, mTLS-Verschlüsselung und detaillierte Traffickontrolle.

- kube-bench unterstützt auch im Netzwerkbereich bei der Überprüfung von CIS-Benchmarks.

Eine Schlüsseltechnologie vieler moderner Tools ist eBPF (extended Berkeley Packet Filter). eBPF erlaubt es, sandboxed Programme direkt im Linux-Kernel auszuführen. Dadurch lassen sich Netzwerkverkehr, Systemaufrufe und Sicherheitsereignisse effizient überwachen – ohne Anpassungen am Anwendungscode. Dank hoher Performance und flexibler Einsatzmöglichkeiten hat sich eBPF im Kubernetes-Umfeld schnell etabliert. Projekte wie Cilium, Calico oder Falco setzen diese Technologie heute produktiv ein.

Container-Sicherheit mit Kontext

Container bilden die kleinste Ausführungseinheit moderner Anwendungen und verdienen besondere Aufmerksamkeit. Jeder Container bringt potenzielle Risiken mit sich, etwa manipulierte Images, fehlerhafte Konfigurationen, Privilege Escalation oder Exploits zur Laufzeit. Ein wirksames Hardening zielt deshalb darauf ab, Schwachstellen im Image, in der Konfiguration und im laufenden Betrieb systematisch zu reduzieren.

Kubernetes stellt dafür bereits Security Contexts und Pod-Security-Standards bereit. Security Contexts konfigurieren Sie direkt in der Pod-Spezifikation und legen damit fest, unter welchen Bedingungen ein Container ausgeführt wird. Sie können Root-Zugriffe unterbinden (runAsNonRoot: true), Privilege Escalation verhindern (allowPrivilegeEscalation: false) und das Dateisystem schreibgeschützt mounten. Eine typische Konfiguration sieht wie folgt aus:

apiVersion: v1

kind: Pod

metadata:

name: secure-pod

spec:

securityContext:

runAsNonRoot: true

runAsUser: 1000

fsGroup: 2000

containers:

- name: app

image: myapp:v1

securityContext:

allowPrivilegeEscalation: false

readOnlyRootFilesystem: true

Mit dieser Definition erzwingen Sie, dass der Container nicht als Root läuft, keine erweiterten Rechte anfordert und das Root-Dateisystem nicht verändern kann. Solche Einstellungen reduzieren das Schadenspotenzial erheblich, falls ein Angreifer in den Container eindringt.

Um Sicherheitsrichtlinien konsistent im gesamten Cluster durchzusetzen, führt Kubernetes seit Version 1.23 die Pod Security Standards (PSS) ein. Der zugehörige Pod Security Admission Controller prüft Pods beim Erstellen und Aktualisieren. Sie aktivieren die Profile über Labels auf Namespace- oder Cluster-Ebene. Kubernetes unterscheidet dabei drei Sicherheitsstufen:

- "Privileged" erlaubt praktisch alles: Root-Container, Host-Namespaces und sämtliche Capabilities. Dieses Profil eignet sich ausschließlich für Systemkomponenten mit besonderen Anforderungen.

- "Baseline" verbietet typische Privilege-Escalation-Techniken, unterbindet Root-Container und schränkt Capabilities ein. Dieses Profil eignet sich für die meisten Standardanwendungen und bietet einen guten Kompromiss aus Sicherheit und Flexibilität.

- "Restricted" erzwingt maximale Isolation. Container laufen ohne Root-Rechte, verlieren sämtliche Capabilities und dürfen nur stark eingeschränkte Volume-Mounts nutzen. Dieses Profil em-pfiehlt sich für sensible Workloads oder Multi-Tenant-Cluster.

Neben der Laufzeitkonfiguration entscheidet auch der Image-Bau über die Sicherheit Ihrer Container. Verwenden Sie möglichst minimale Basis-Images wie alpine oder distroless, um die Angriffsfläche zu verkleinern. Halten Sie diese Images aktuell und definieren Sie für alle Pods CPU- und Speicherlimits, um Denial-of-Service-Szenarien zu vermeiden. Beziehen Sie Images ausschließlich aus vertrauenswürdigen Registries und integrieren Sie Sicherheitsprüfungen fest in Ihre CI/CD-Pipeline.

Für diese Aufgaben existiert ein breites Ökosystem an Werkzeugen. Trivy scannt Container-Images automatisiert auf bekannte Schwachstellen. Falco  erkennt verdächtiges Verhalten zur Laufzeit, etwa ungewöhnliche Systemaufrufe oder unautorisierte Shell-Zugriffe. Gatekeeper in Kombination mit dem Open Policy Agent (OPA) setzt Richtlinien bereits bei der Erstellung von Kubernetes-Ressourcen durch. OPA fungiert als allgemeine Policy-Engine und behandelt Sicherheitsregeln als Code. Sie formulieren Richtlinien in der deklarativen Sprache Rego und wenden sie über Admission Controller auf Kubernetes-Objekte an. Das folgende Beispiel blockiert Pods, die als Root laufen:

package kubernetes.admission

deny[msg] {

input.request.kind.kind == "Pod"

container := input.request.object.spec. containers[_]

container.securityContext. runAsUser == 0

msg := "Pods dürfen nicht als Root laufen"

}

Diese Regel greift bei jeder Pod-Erstellung. Erkennt sie einen Container mit "runAsUser: 0", lehnt Kubernetes den Request ab und gibt die definierte Fehlermeldung zurück. So verhindern Sie Fehlkonfigurationen bereits vor dem Start der Workloads.

Für die Runtime-Sicherheit ergänzt Falco dieses Modell. Falco überwacht das tatsächliche Verhalten von Containern und Nodes in Echtzeit. Es analysiert Systemaufrufe, Dateizugriffe, Netzwerkverbindungen und Prozessstarts direkt im Kernel und erkennt Abweichungen vom Normalverhalten. Grundlage dafür bildet eBPF, das eine performante und sichere Ereigniserfassung ermöglicht.

Das Tool besteht aus mehreren Komponenten: Der Falco-Driver erfasst Kernel-Events, die Falco-Engine reichert sie mit Kubernetes-Kontext an und wertet sie anhand definierter Regeln aus. Erkennt Falco verdächtige Aktivitäten – etwa das Öffnen einer Shell in einem produktiven Container –, löst es sofort Alerts aus. Während OPA Fehlkonfigurationen beim Erstellen von Ressourcen verhindert, schützt Falco den Cluster im laufenden Betrieb.

Sichere Cluster-Konfiguration

Nicht nur Pods benötigen Schutz, auch auf Cluster-Ebene lassen sich zentrale Sicherheitsmechanismen durchsetzen. Viele Kubernetes-Distributionen liefern hier bereits einen soliden Grundschutz, den Sie gezielt ergänzen und überprüfen sollten. Zu den wichtigsten Maßnahmen zählen:

- Absicherung des API-Servers: Erzwingen Sie HTTPS für sämtliche API-Zugriffe, deaktivieren Sie anonymen Zugriff vollständig und schränken Sie die erreichbaren IP-Adressen konsequent ein.

- Verschlüsselung der etcd-Datenbank: Da etcd den gesamten Cluster-Zustand speichert, gehört eine Verschlüsselung der Daten zu den elementaren Sicherheitsmaßnahmen.

- Authentifizierung für Kubelets: Auch die Kommunikation mit den Knoten sollte nicht ungeschützt erfolgen. Aktivieren Sie deshalb Authentifizierungs- und Autorisierungsmechanismen für Kubelets.

- Audit-Logging: Protokollieren Sie API-Zugriffe, um sicherheitsrelevante Aktionen nachvollziehen zu können.

- Regelmäßige Updates: Halten Sie Kubernetes und alle Kernkomponenten aktuell, um bekannte Schwachstellen zu schließen.

Besondere Aufmerksamkeit verdienen die Audit-Logs. Sie fungieren als chronologisches Protokoll aller Aktionen, die über den API-Server erfolgen, und beantworten zentrale Fragen: Was ist passiert? Wann? Und wer hat die Aktion ausgelöst? Abhängig von der verwendeten Distribution konfigurieren Sie die Audit-Logs über eine AuditPolicy. In Managed-Kubernetes-Angeboten wie GKE, AKS oder EKS lässt sich diese Policy oft nicht direkt anpassen, die Logs stehen jedoch über die jeweiligen Cloud-Logging-Dienste zur Verfügung. Unabhängig davon sollten Sie die Auditdaten immer zentral weiterleiten, etwa über Fluentd oder Fluent Bit an einen ELK-Stack oder ein vergleichbares Logbackend, um sie dauerhaft auszuwerten.

Geheimnisse im Griff

Das Management von Secrets spielt eine wichtige Rolle, da Kubernetes-Cluster regelmäßig mit sensiblen Informationen wie API-Schlüsseln, Zugangsdaten oder Zertifikaten arbeiten. Kubernetes stellt dafür zwar native Secret-Objekte bereit, speichert deren Inhalte jedoch lediglich Base64-kodiert und nicht verschlüsselt. Für produktive Umgebungen genügt das nicht. Bewährte Best Practices umfassen deshalb:

- Verschlüsselung von etcd: Stellen Sie sicher, dass die etcd-Datenbank verschlüsselt ist. In Cloudumgebungen ermöglichen Hyperscaler dies häufig über Customer Managed Encryption Keys (CMEK). Alternativ konfigurieren Sie die Verschlüsselung selbst über ein EncryptionConfiguration-Manifest.

- Zugriff über RBAC einschränken: Begrenzen Sie den Zugriff auf Secrets strikt. In Produktionsumgebungen sollten nur explizit autorisierte Service Accounts Lesezugriff erhalten.

- Externe Secret-Management-Systeme nutzen: Ziehen Sie dedizierte Produkte in Betracht. In der Public Cloud bieten sich Dienste wie AWS Secrets Manager oder Azure Key Vault an, im eigenen Rechenzentrum hat sich HashiCorp Vault etabliert.

Um dabei unabhängig vom jeweiligen Anbieter zu bleiben, empfiehlt sich der Einsatz des External Secrets Operator. Dieses Werkzeug synchronisiert Secrets aus externen Systemen automatisch in Kubernetes und stellt sie dort als native Secret-Objekte bereit. So trennen Sie die sichere Verwaltung sensibler Daten von deren Nutzung im Cluster.

Fazit

In Kubernetes-Umgebungen mit produktiven Workloads ist Security-Hardening längst kein Nice-to-have mehr, sondern eine grundlegende Voraussetzung für Stabilität, Compliance und Vertrauen. Der Artikel beleuchtet die zentralen Handlungsfelder – von Zugriffskontrolle und Netzwerksicherheit über Container- und Cluster-Hardening bis hin zum sicheren Umgang mit Secrets.

In Kombination mit leistungsfähigen Werkzeugen wie OPA und Gatekeeper, die Sicherheitsrichtlinien deklarativ durchsetzen, entsteht ein ganzheitliches Sicherheitskonzept, das Kubernetes-Cluster nachhaltig absichert. Wer Hardening als fortlaufenden Prozess begreift und Security-Checks fest in CI/CD-Pipelines verankert, schafft eine belastbare Grundlage für den sicheren Betrieb geschäftskritischer Workloads.