Kubernetes Security Hardening: 32-Punkte-Checkliste für Production

Pexon Consulting | 12 Min. Lesezeit | 13.05.2026

TL;DR

Kubernetes Security Hardening heißt: API-Server, Workloads, Netzwerk, Secrets und Supply Chain auf ein verteidigungsfähiges Niveau bringen – nicht durch ein einzelnes Tool, sondern durch 32 konkrete Konfigurationen, die zusammenwirken. Pexon Consulting auditiert und härtet AKS-, EKS- und GKE-Cluster nach CIS Benchmark und BSI-Vorgaben. Unsere Kunden schließen in 6 bis 8 Wochen die kritischsten 25 Hardening-Punkte und reduzieren das angreifbare Cluster-Surface um 70 bis 85 Prozent.

Warum Stock-Cluster auf jeder Cloud unsicher sind

Wenn Sie heute auf Azure einen neuen AKS-Cluster, auf AWS einen EKS oder auf GCP einen GKE Standard hochziehen, bekommen Sie eine funktionierende Container-Plattform – aber keine gehärtete. Defaults sind auf Lauffähigkeit optimiert, nicht auf Sicherheit. Das ist auch nicht der Job der Cloud-Anbieter. Das ist Ihr Job.

Wir auditieren regelmäßig Cluster, die seit 18 Monaten in Production laufen. Die wiederkehrenden Befunde:

• Default Service Account hat Cluster-weite Read-Rechte
• Keine Network Policies, alle Pods können mit allen Pods sprechen
• Pods laufen als Root, oft mit Linux Capabilities die niemand braucht
• Secrets liegen als Plaintext in ConfigMaps oder direkt im Image
• Container-Images werden nie auf CVEs gescannt
• Etcd-Daten unverschlüsselt auf den Control-Plane-Nodes
• Audit-Log existiert, wird aber nirgendwo gelesen

Jeder einzelne Punkt ist eine offene Tür. Zusammen sind sie die Karte, mit der ein Angreifer aus einem kompromittierten Service-Account in 5 bis 15 Minuten zum Cluster-Admin wird. CrowdStrike hat 2024 in 38 Prozent der untersuchten Cluster-Compromises genau dieses Muster gesehen – Initial-Foothold durch ein anfälliges Container-Image, dann Lateral Movement über offene Network-Pfade, dann Privilege Escalation über überprivilegierte Service Accounts.

Das gute: Es gibt keine Magie. 32 konkrete Konfigurationen schließen 95 Prozent dieser Angriffspfade. Hier sind sie.

Block 1: Control Plane und API Server (8 Punkte)

Der API Server ist das Hirn jedes Clusters. Wer ihn kompromittiert, hat alles.

1. Etcd Encryption at Rest aktivieren. Etcd speichert alle Cluster-Daten inklusive Secrets. Auf AKS via enable-encryption-at-host, auf EKS via KMS, auf GKE via Application-Layer Secrets Encryption. Ohne diese Einstellung liegen Secrets unverschlüsselt auf dem Control-Plane-Disk.

# AKS: Etcd-Verschlüsselung mit Customer-Managed Key (CMK)
az aks update 
  --resource-group rg-prod 
  --name aks-prod 
  --enable-azure-keyvault-kms 
  --azure-keyvault-kms-key-id "https://kv-prod.vault.azure.net/keys/aks-etcd"

2. Audit Logging aktivieren und auswerten. Ein Audit-Log, das niemand liest, ist nutzlos. Wir empfehlen Audit-Level RequestResponse für Auth-Events, Metadata für alles andere. Logs gehen in eine separate Log-Senke (Log Analytics, CloudWatch, GCP Logging) mit 90 Tage Retention.

3. RBAC strict konfiguriert. Kein Cluster-Admin-Token in CI/CD. Service Accounts bekommen nur die Rechte, die sie wirklich brauchen. Default Service Account ohne Berechtigungen (automountServiceAccountToken: false).

4. Anonymous Auth disabled. API Server darf keine anonymen Anfragen akzeptieren. Standard auf AKS und EKS, aber bei selbst gemanagten Clustern prüfen.

5. Webhook-basierte Auth oder OIDC mit dem IdP. Keine statischen Tokens, kein Basic Auth. Auf AKS: Azure AD Integration. Auf EKS: AWS IAM oder OIDC zu Entra/Okta. Auf GKE: Workload Identity Federation.

6. Control Plane nur über Private Endpoint erreichbar. Public API Server ist Angriffsfläche. Auf AKS: Private Cluster. Auf EKS: Private API Endpoint. Auf GKE: Authorized Networks plus Private Cluster.

7. Admission Controller aktiviert. Mindestens OPA Gatekeeper oder Kyverno. Diese verhindern, dass nicht-konforme Workloads überhaupt im Cluster landen – Stichwort „shift left bei der Cluster-Tür“.

8. CIS Kubernetes Benchmark regelmäßig laufen lassen. Kube-Bench monatlich gegen den Cluster, Drift-Erkennung in den Hardening-Score. Wir empfehlen Mindest-Score 85 Prozent für Production.

Block 2: Pod Security und Workload Hardening (10 Punkte)

Pod Security Standards (PSA) haben 2022 die alten Pod Security Policies abgelöst. Drei Profile: privileged, baseline, restricted. Wir empfehlen für Production-Namespaces immer restricted, für System-Namespaces baseline mit Begründung.

9. Pod Security Admission auf `restricted` für alle App-Namespaces.

apiVersion: v1
kind: Namespace
metadata:
  name: prod-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

10. Container laufen non-root. runAsNonRoot: true im SecurityContext. Bei Legacy-Images, die Root brauchen, sauberen Rebuild planen. Workaround mit runAsUser: 1000 ist akzeptabel, wenn das Image das unterstützt.

11. Read-only root filesystem. readOnlyRootFilesystem: true. Wenn die Anwendung temporäre Dateien braucht, gezielte emptyDir Mounts statt offenes Root-FS.

12. Linux Capabilities droppen. Default ist eine Liste von 14 Capabilities, von denen 99 Prozent der Anwendungen 0 brauchen. drop: ["ALL"], dann gezielt nur die benötigten zurückholen.

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

13. allowPrivilegeEscalation: false. Verhindert, dass ein Prozess sich nachträglich mehr Rechte holt. Default ist true – also explizit setzen.

14. Seccomp-Profil RuntimeDefault oder strenger. Schränkt System Calls ein, die der Container machen darf. RuntimeDefault ist ein guter Einstieg, eigene Profile für sicherheitskritische Workloads.

15. Resource Limits PFLICHT. Pods ohne CPU- und Memory-Limits können den Node aushungern (DoS gegen andere Workloads). LimitRange pro Namespace, der das erzwingt.

16. Privileged Container nur in Ausnahmefällen. Wenn ein Vendor „privileged: true“ fordert, fragen Sie warum. In 9 von 10 Fällen ist eine alternative Lösung möglich (CSI, Device Plugin, Sidecar mit gezielten Capabilities).

17. HostPath Volumes verbieten. Ein HostPath-Mount auf /, /var/run/docker.sock oder /proc ist quasi Root auf dem Node. Per OPA/Kyverno hart unterbinden, Ausnahmen nur über schriftlichen Antrag.

18. Image Pull Policies und Image Provenance. imagePullPolicy: Always für getaggte :latest-Builds (die Sie nicht haben sollten), bei Digest-Pins egal. Wichtiger: Image-Signaturen prüfen (Cosign, Sigstore).

Block 3: Netzwerk und Service-Kommunikation (6 Punkte)

Default-Verhalten in Kubernetes: jeder Pod kann jeden Pod auf jedem Port erreichen. Das ist 2026 nicht mehr akzeptabel.

19. Default-Deny Network Policy pro Namespace. Erst alles blockieren, dann gezielt erlauben.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: prod-app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

20. Explizite Egress-Policies. Workloads dürfen nicht beliebig ins Internet. DNS auf Cluster-Resolver, ausgehende Calls nur zu definierten Zielen. Verhindert Data Exfiltration im Kompromittierungsfall.

21. Service Mesh für mTLS bei kritischen Services. Istio, Linkerd oder Cilium Service Mesh. Workload-zu-Workload-Verkehr verschlüsselt und auth’d, auch innerhalb des Clusters. Bei sicherheitskritischen Banking- oder Versicherungs-Clustern Pflicht.

22. Ingress mit WAF davor. Cloudflare WAF, Azure Application Gateway WAF oder AWS WAF. NICHT der Ingress Controller selbst – der ist nicht für L7-Angriffe gebaut.

23. Network Policy CNI prüfen. Calico, Cilium oder Azure Network Policies. Standard auf AKS ist KEIN Network Policy Enforcer – explizit aktivieren. Auf EKS Calico installieren. Auf GKE Network Policy aktivieren.

24. Cluster-zu-Cluster und Cluster-zu-Datenbank über Private Link. Keine Public Endpoints für Datenbanken, die der Cluster erreicht. Private Endpoint oder VPC Peering. Ein offener Postgres-Port ist 2026 unverzeihlich.

Block 4: Secrets, Identity und Supply Chain (8 Punkte)

Hier passieren die meisten praktischen Kompromittierungen.

25. Externes Secrets-Management. Azure Key Vault, AWS Secrets Manager, HashiCorp Vault. Sync via External Secrets Operator oder Azure Key Vault Provider for Secrets Store CSI Driver. Niemals Secrets in Git, auch nicht verschlüsselt (Sealed Secrets ist OK als Fallback, aber zweite Wahl).

26. Workload Identity statt Service-Account-Tokens. Auf AKS: Azure AD Workload Identity. Auf EKS: IAM Roles for Service Accounts (IRSA). Auf GKE: Workload Identity. Keine langlebigen Cloud-Credentials im Pod.

27. Image Scanning in der CI-Pipeline. Trivy für den automatisierten Scan, Grype oder Snyk. Build bricht ab bei Critical CVEs. Bei High CVEs Warnung, bei Medium Reporting. Image-Tag-Allowlist via OPA: nur Images aus dem hauseigenen Registry, nur signiert.

28. Image-Signaturen via Cosign verifizieren. Sigstore-basiert, klein, funktioniert. Admission Controller prüft Signatur und Provenance (SLSA) beim Pod-Start.

# Cosign-Signatur prüfen vor Deployment
cosign verify 
  --certificate-identity-regexp "https://github.com/pexon/.*" 
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" 
  ghcr.io/pexon/app:v1.4.2

29. SBOM für jedes Image. Software Bill of Materials per Syft generiert, ans Image attached. Bei einem neuen CVE wissen Sie in 10 Minuten, welche Cluster-Workloads betroffen sind, statt in 3 Wochen.

30. Registry-Authentifizierung verpflichtend. Keine Public-Pulls aus Docker Hub ohne Auth (Rate Limits, plus Supply Chain Risk). Eigene Registry oder Pull Cache als Single Source.

31. CI/CD Pipeline mit minimal-rechtigen Tokens. Der Deploy-Service-Account darf nicht Cluster-Admin sein. Nur die Namespaces deployen können, die er deployen muss.

32. Runtime Security mit Falco oder vergleichbar. Erkennt anomales Verhalten zur Laufzeit – Shell in Production-Pod, ungewohnte System-Calls, Auslesen sensibler Dateien. Alerts gehen in Ihr SIEM, nicht auf einen ungelesenen Slack-Channel.

Auf Azure lassen sich diese Blöcke nicht generisch abarbeiten, weil Identity, Secrets und Policy dort an Entra ID, Key Vault und Azure Policy hängen. Wer den Cluster gleich richtig aufsetzt, statt später nachzuhärten, lässt den AKS-Cluster mit Entra ID, Managed Identity und Azure Policy absichern.

Was das in der Praxis bedeutet – Stand vor und nach Hardening

Ein typischer mittelständischer Kunde mit 4 AKS-Clustern (Dev, Test, Prod, DR) und 180 produktiven Workloads kommt vor dem Hardening auf einen CIS-Benchmark-Score zwischen 35 und 50 Prozent. Das ist nicht ungewöhnlich. Wir haben das in 2025 bei sieben von zehn auditierten Mittelstand-Clustern so gesehen. Wo Ihre Umgebung auf dieser Skala steht, zeigt eine Bestandsaufnahme, bei der Sie den Cluster gegen den CIS-Benchmark prüfen lassen.

Nach einem 6- bis 8-wöchigen Hardening-Projekt mit zwei Pexon-Engineers plus Ihrer Plattform-Team liegen wir bei 85 bis 95 Prozent CIS-Score. Die verbleibenden 5 bis 15 Prozent sind dokumentierte Ausnahmen mit Geschäftsbegründung – meistens Vendor-Workloads, die ohne Privileged nicht laufen, und für die wir gezielte Kompensations-Controls bauen.

Die Investition: typisch 50.000 bis 120.000 EUR für ein vollständiges Hardening-Programm. Die alternative Investition – ein Cluster-Compromise mit Ransomware oder Datenleak – kostet die meisten Mittelständler 800.000 bis 3 Millionen EUR, ohne den Reputationsschaden zu rechnen.

Wir raten davon ab, Hardening „irgendwann selbst nebenher zu machen“. Das ist genau das, was bei 60 Prozent der Cluster passiert, die wir später kompromittiert oder hochrisikofähig vorfinden. Hardening ist ein fokussiertes 6-bis-8-Wochen-Projekt, das danach in regelmäßige Audits übergeht.

Worauf Sie bei der Auswahl achten sollten

Fünf Punkte, an denen wir Security-Anbieter im Markt durchfallen sehen:

1. CIS-Benchmark-Erfahrung in Production-Clustern. Theorie reicht nicht. Lassen Sie sich konkret zeigen, welche Tools (kube-bench, kubescape, Trivy) die Anbieter mit welchen Auswertungs-Mustern einsetzen.
2. Cloud-spezifische Tiefe. AKS, EKS und GKE haben unterschiedliche Hardening-Pfade. Ein „Kubernetes-generischer“ Anbieter wird auf AKS 30 Prozent Effizienz verlieren, weil er Azure-Spezifika nicht kennt.
3. Werkzeug-Agnostisch bei der Empfehlung. Wenn der Anbieter immer das gleiche kommerzielle Tool empfiehlt, prüfen Sie die Affiliation. Wir empfehlen je nach Kontext OPA Gatekeeper oder Kyverno, Falco oder Tetragon, Trivy oder Snyk.
4. GitOps-First. Hardening-Konfiguration gehört in Git, nicht in den Cluster per kubectl-Apply. ArgoCD oder Flux als Standard.
5. Übergabe an Ihr Team. Ein Hardening-Projekt ist gescheitert, wenn nur der externe Berater weiß, was eingestellt ist. Pflicht: Runbook, Architektur-Doku, hands-on Schulung für Ihre SREs.

Häufig gestellte Fragen

Was kostet ein Kubernetes Security Hardening Projekt?

Für einen typischen Mittelstand-Setup mit 2 bis 6 Clustern und 50 bis 300 Workloads liegen wir zwischen 50.000 und 120.000 EUR. Die Spanne hängt an Cluster-Anzahl, Tiefe des Audits (kube-bench plus manuelle Penetration-Tests sind teurer als nur kube-bench), und ob wir das Hardening selbst implementieren oder nur Empfehlungen liefern. Wiederkehrende Re-Audits danach kosten 8.000 bis 18.000 EUR pro Quartal.

Sollten wir bei Hardening auf einen Cluster Service Mesh wie Istio setzen?

Kommt auf den Use Case an. Für mTLS innerhalb des Clusters und Traffic-Policies ist Istio oder Linkerd ein starkes Werkzeug – aber Komplexität und Performance-Overhead sind real. Für Cluster mit unter 50 Services würden wir aktuell Cilium mit Cluster-Mesh empfehlen statt Istio. Bei hundert plus Services und harten Compliance-Anforderungen Istio mit Ambient Mode (seit 1.22 GA).

Wie verhindern wir, dass nach unserem Hardening die Entwickler den Cluster wieder unsicher konfigurieren?

Drei Mechanismen. Erstens: OPA Gatekeeper oder Kyverno mit Policies, die unsichere Konfigurationen am Admission Controller ablehnen – das geht gar nicht erst durch. Zweitens: kube-bench läuft täglich, Drift wird im Slack-Channel oder Teams alarmiert. Drittens: GitOps mit ArgoCD oder Flux verhindert direkte kubectl-Edits in Production. Wie diese Signale im laufenden Cluster zusammenlaufen, also Metriken, Logs und Alarme an einer Stelle, beschreiben wir unter Kubernetes-Observability im Betrieb.

Kubernetes vs. Pod Security Standards vs. Pod Security Policies – was ist aktuell?

Pod Security Policies sind seit Kubernetes 1.25 entfernt. Pod Security Admission (PSA) mit den drei Standards privileged, baseline, restricted ist der offizielle Nachfolger und seit 1.25 GA. Wir setzen PSA als Basis und ergänzen mit OPA Gatekeeper oder Kyverno für komplexere Regeln (z.B. Image-Allowlists, Pflicht-Labels, Vault-Annotations).

Wie gehen wir mit Legacy-Workloads um, die `runAsRoot` oder `privileged` brauchen?

Drei Optionen – in dieser Reihenfolge: Erstens prüfen, ob es wirklich nötig ist (oft nicht). Zweitens, ob es eine alternative Image-Variante des Vendors gibt (häufig ja). Drittens, wenn keine der ersten beiden funktioniert: dedizierter Namespace mit baseline statt restricted, mit Network Policy isoliert, in einem separaten Node Pool mit kürzerer Patch-SLA. Das Risiko bleibt – aber es wird sichtbar und gezielt minimiert.

Nächster Schritt

Verwandte Themen