Kubernetes absichern: Hardening-Guide für den Mittelstand

Ein laufender Kubernetes-Cluster ist kein sicherer Kubernetes-Cluster. Die Default-Konfiguration von Kubernetes ist bewusst permissiv gehalten — sie soll den Einstieg erleichtern, nicht Produktionsumgebungen schützen. Wer Kubernetes im Mittelstand betreibt, trägt Verantwortung für Kundendaten, interne Systeme und regulatorische Anforderungen. Dieser Leitfaden zeigt, welche Maßnahmen den größten Sicherheitsgewinn bringen und in welcher Reihenfolge sie sinnvoll umgesetzt werden.

Warum Kubernetes-Sicherheit kein Einmalprojekt ist

Kubernetes entwickelt sich schnell. Neue Features, neue Angriffsvektoren, neue Best Practices — das CIS Kubernetes Benchmark wird regelmäßig aktualisiert, und was vor zwei Jahren als sicher galt, ist es heute möglicherweise nicht mehr. Sicherheit in Kubernetes ist ein kontinuierlicher Prozess, der in den normalen Betrieb integriert sein muss: in CI/CD-Pipelines, in Code-Reviews, in Upgrade-Zyklen.

Gleichzeitig ist der Scope überschaubar. Kubernetes bietet native Sicherheitsmechanismen, die — konsequent eingesetzt — einen sehr hohen Schutz bieten. Der häufigste Befund in Sicherheits-Audits ist nicht das Fehlen exotischer Tools, sondern das Nicht-Nutzen vorhandener Mechanismen.

Schicht 1: RBAC konsequent umsetzen

Role-Based Access Control (RBAC) ist in Kubernetes seit Version 1.8 standardmäßig aktiviert — aber selten konsequent konfiguriert. Die häufigsten Fehler:

• ClusterAdmin für Service Accounts: Viele Helm-Charts fordern weitreichende Rechte an, die für den eigentlichen Betrieb nicht benötigt werden. Jeder Service Account sollte nur die Rechte haben, die er tatsächlich braucht.
• Wildcard-Permissions: verbs: ["*"] in RoleBindings ist ein Anti-Pattern. Erlaubte Operationen sollten explizit aufgelistet werden.
• Keine Trennung zwischen Namespaces: Cluster-weite Roles, wo Namespace-scoped Roles ausreichen würden, vergrößern die Angriffsfläche unnötig.

Ein einfacher Einstieg: kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:SERVICEACCOUNT zeigt, welche Rechte ein Service Account tatsächlich hat. Das Ergebnis ist oft überraschend.

Schicht 2: Network Policies — Kommunikation explizit erlauben

Ohne Network Policies kann jeder Pod im Cluster mit jedem anderen Pod kommunizieren. Das ist für Entwicklungsumgebungen praktisch, für Produktionsumgebungen inakzeptabel. Network Policies definieren, welche Verbindungen erlaubt sind — alles andere wird blockiert.

Die empfohlene Vorgehensweise:

1. Default-Deny pro Namespace: Eine Policy, die allen eingehenden und ausgehenden Traffic blockiert, als Baseline.
2. Explizite Freigaben: Nur die tatsächlich benötigten Verbindungen werden erlaubt — zum Beispiel Frontend → Backend, Backend → Datenbank.
3. Egress einschränken: Pods sollten nicht beliebig ins Internet kommunizieren können. Egress-Policies auf bekannte Endpunkte beschränken.

Wichtig: Network Policies werden vom CNI-Plugin umgesetzt. Nicht jedes CNI unterstützt alle Policy-Features vollständig. Cilium bietet hier den größten Funktionsumfang — einschließlich Layer-7-Policies auf DNS- und HTTP-Ebene.

Schicht 3: Pod Security Standards durchsetzen

Seit Kubernetes 1.25 sind Pod Security Policies durch Pod Security Standards (PSS) ersetzt worden. PSS definiert drei Profile:

• Privileged: Keine Einschränkungen. Nur für System-Namespaces geeignet.
• Baseline: Verhindert bekannte Privilege-Escalation-Angriffe. Guter Startpunkt für die meisten Workloads.
• Restricted: Folgt aktuellen Best Practices. Erfordert explizite Konfiguration der Workloads.

Die Durchsetzung erfolgt über Labels am Namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Der warn-Modus gibt Hinweise ohne zu blockieren — ideal, um den Ist-Zustand zu erfassen, bevor enforce aktiviert wird.

Schicht 4: Image-Scanning und Supply Chain Security

Ein sicher konfigurierter Cluster hilft wenig, wenn die laufenden Container bekannte CVEs enthalten. Image-Scanning sollte Teil der CI/CD-Pipeline sein, nicht ein nachgelagerter Schritt.

Etablierte Tools:

• Trivy: Schnell, einfach integrierbar, deckt OS-Pakete und Anwendungsabhängigkeiten ab.
• Grype: Alternative mit gutem SBOM-Support.
• Cosign / Sigstore: Image-Signierung — stellt sicher, dass nur geprüfte Images in den Cluster gelangen.

Ergänzend: Admission Controller wie Kyverno können durchsetzen, dass nur Images aus vertrauenswürdigen Registries mit gültigem Signature ausgeführt werden. Das schließt eine Lücke, die reines Scanning offen lässt.

Schicht 5: Secrets Management

Kubernetes Secrets sind standardmäßig nur Base64-kodiert — nicht verschlüsselt. Wer Secrets in etcd speichert, ohne Encryption at Rest zu aktivieren, speichert sie im Klartext auf Disk. Die Lösung:

• Encryption at Rest aktivieren: Über die EncryptionConfiguration des API-Servers mit AES-GCM oder einem KMS-Provider.
• External Secrets Operator: Secrets werden nicht in Kubernetes gespeichert, sondern zur Laufzeit aus einem externen Vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) geladen. Das Kubernetes-Secret ist kurzlebig und enthält nur den aktuellen Wert.
• Sealed Secrets: Für GitOps-Workflows — verschlüsselte Secrets können sicher im Git-Repository gespeichert werden.

Schicht 6: Laufzeit-Sicherheit mit Falco

Alle bisherigen Maßnahmen sind präventiv. Falco ergänzt das Bild um eine Detektionsschicht: Es überwacht Syscalls und Kubernetes-Audit-Events in Echtzeit und schlägt Alarm bei verdächtigem Verhalten — zum Beispiel wenn ein Container eine Shell öffnet, auf /etc/passwd zugreift oder eine Netzwerkverbindung zu einem unbekannten Ziel aufbaut.

Falco lässt sich mit bestehenden SIEM-Systemen integrieren und ist CNCF-Projekt mit breiter Unterstützung. Für Mittelstandsunternehmen mit begrenzten Security-Ressourcen ist Falco eine effiziente Methode, Angriffe zu erkennen, die alle anderen Schichten überwunden haben.

Priorisierung: Wo anfangen?

Nicht jedes Team hat die Kapazität, alle Schichten gleichzeitig umzusetzen. Eine pragmatische Reihenfolge nach Aufwand/Nutzen-Verhältnis:

1. RBAC-Audit und Bereinigung (hoher Nutzen, überschaubarer Aufwand)
2. Pod Security Standards im warn-Modus aktivieren (geringer Aufwand, gute Sichtbarkeit)
3. Network Policies: Default-Deny + explizite Freigaben (mittlerer Aufwand, hoher Nutzen)
4. Image-Scanning in CI/CD integrieren (einmaliger Setup-Aufwand)
5. Secrets Management mit External Secrets Operator (mittlerer Aufwand)
6. Falco für Laufzeit-Detektion (niedriger laufender Aufwand nach Setup)

Fazit

Kubernetes absichern ist keine Frage des richtigen Tools, sondern der konsequenten Anwendung vorhandener Mechanismen. RBAC, Network Policies, Pod Security Standards und Image-Scanning sind in Kubernetes bereits eingebaut — sie müssen nur aktiviert und konfiguriert werden. Externe Tools wie Falco, External Secrets Operator und Kyverno ergänzen das Bild für Teams, die eine vollständige Defense-in-Depth-Strategie umsetzen wollen.

Der erste Schritt ist eine ehrliche Bestandsaufnahme: Was ist heute konfiguriert, was fehlt, wo sind die größten Risiken? Genau das leisten wir im Rahmen eines strukturierten Audits.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.