Kubernetes Cluster absichern: Security-Check und Härtungs-Checkliste für 2026

TL;DR

Ein Kubernetes-Cluster hat sechs Angriffsflächen: API-Server, RBAC, Netzwerk, Secrets, Images und Nodes. Die meisten Cluster im deutschen Mittelstand sind auf mindestens drei davon offen — nicht wegen exotischer Zero-Days, sondern wegen Defaults, die nie angefasst wurden. Dieser Artikel liefert einen 30-Minuten-Quick-Check mit drei kostenlosen Tools (kube-bench, Trivy, Polaris), die YAML-Manifeste für NetworkPolicy default-deny und Pod Security Standards restricted sowie eine 12-Punkte-Härtungs-Checkliste, die Sie einem Kunden oder Auditor vorlegen können.

Das Problem: Der Default-Cluster ist offen

Kubernetes ist ab Werk auf Entwicklerproduktivität optimiert, nicht auf Sicherheit. Ein frisch aufgesetzter Cluster — egal ob kubeadm, AKS, EKS oder GKE — hat typischerweise:

• Keine NetworkPolicies. Jeder Pod kann mit jedem Pod reden, über alle Namespaces hinweg. Ein kompromittierter Frontend-Container erreicht Ihre Datenbank direkt.
• Keine Pod Security Standards. Container dürfen als root laufen, privilegiert starten und Host-Pfade mounten.
• Secrets nur base64-kodiert. Wer get-Rechte auf Secrets hat, liest sie im Klartext. Ohne Encryption at Rest liegen sie auch in etcd unverschlüsselt.
• Überbreite RBAC-Bindings. cluster-admin für das CI/CD-System, weil es "sonst nicht funktioniert hat".

Der Anlass, das zu ändern, kommt bei SaaS-Firmen mit 10 bis 100 Mitarbeitern fast immer von außen: Ein Enterprise-Kunde schickt einen Sicherheitsfragebogen, ein ISO-27001- oder TISAX-Audit steht an, oder die Cyber-Versicherung fragt nach dem Stand der Containersicherheit. Dann brauchen Sie zwei Dinge: einen belastbaren Ist-Zustand und einen dokumentierten Härtungsstand. Beides liefert dieser Artikel.

Wenn Sie den formalen Audit-Prozess dahinter aufsetzen wollen, finden Sie die Prozess-Seite in unserer Kubernetes Security-Audit-Checkliste — hier geht es um die technische Durchführung.

Grundlagen: Die sechs Angriffsflächen

Bevor Sie Tools laufen lassen, sollten Sie wissen, was Sie prüfen. Ein Kubernetes-Cluster hat sechs relevante Angriffsflächen:

Die Reihenfolge ist bewusst gewählt: API-Server und RBAC sind die Kronjuwelen. Wer dort durchkommt, braucht die anderen vier Flächen nicht mehr.

Praxis: Der 30-Minuten-Quick-Check

Drei Open-Source-Tools decken die sechs Flächen weitgehend ab. Alle drei laufen ohne Agent-Installation und ohne Cluster-Änderung — Sie können sie gefahrlos auf Produktion loslassen.

1. kube-bench: CIS-Benchmark gegen Control Plane und Nodes

kube-bench von Aqua Security prüft Ihren Cluster gegen den CIS Kubernetes Benchmark. Auf einem selbstverwalteten Cluster starten Sie es als Job:

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Ein typisches Finding auf einem ungehärteten kubeadm-Cluster:

[FAIL] 1.2.16 Ensure that the --profiling argument is set to false (Automated)
[FAIL] 1.2.21 Ensure that the --audit-log-path argument is set (Automated)
[WARN] 1.1.9 Ensure that the Container Network Interface file permissions are set to 600 or more restrictive
[FAIL] 4.2.6 Ensure that the --protect-kernel-defaults argument is set to true (Automated)

Realistisch sehen Sie auf einem Default-kubeadm-Cluster 15 bis 30 FAILs (Schätzung aus eigener Praxis, kein Benchmark-Wert). Bei Managed Kubernetes (AKS/EKS/GKE) fällt die Control-Plane-Sektion weg — der Provider ist zuständig — aber die Node- und Policy-Checks bleiben Ihr Problem. Die Details zur Abarbeitung der einzelnen CIS-Findings haben wir im Artikel Kubernetes CIS-Benchmark-Hardening aufgeschlüsselt.

2. Trivy: CVEs und Fehlkonfigurationen im Cluster

Trivy scannt laufende Workloads auf bekannte Schwachstellen und Misconfigurations:

trivy k8s --report summary

Für einen einzelnen kritischen Namespace mit vollem Report:

trivy k8s --include-namespaces production --report all --severity HIGH,CRITICAL

Ein typisches Finding:

production/deployment-api (alpine 3.17.2)
Total: 14 (HIGH: 11, CRITICAL: 3)

CVE-2023-42363  busybox  CRITICAL  1.35.0-r29  fixed in 1.36.1-r0

Wichtig beim Lesen: Nicht jede CRITICAL-CVE ist ein akutes Risiko. Prüfen Sie, ob die verwundbare Komponente überhaupt erreichbar ist. Aber ein Image mit drei CRITICALs, das seit acht Monaten nicht neu gebaut wurde, ist ein Prozess-Problem, kein Einzelfall.

3. Polaris: Workload-Hygiene

Polaris von Fairwinds bewertet Ihre Deployments gegen Best Practices — läuft der Container als root, fehlen Resource-Limits, ist das Filesystem beschreibbar:

polaris audit --format=pretty

Beispiel-Output:

Deployment production/api
  ❌ runAsNonRoot: Container should not run as root
  ❌ readOnlyRootFilesystem: Filesystem should be read only
  ❌ cpuLimitsMissing: CPU limits should be set
  ✅ pullPolicyNotAlways: passed

Polaris liefert einen Score von 0 bis 100. Unter 70 heißt: Ihre Workload-Manifeste haben systematische Lücken. Einzelne Manifeste können Sie vor dem Deploy auch direkt gegen DSGVO- und BSI-relevante Regeln prüfen — dafür haben wir den kostenlosen YAML-Validator gebaut.

Ergänzend, wenn Sie tiefer wollen: rbac-lookup zeigt, wer welche Rolle hat (rbac-lookup --kind user), kubeaudit prüft Security-Kontexte (kubeaudit all), und kube-hunter simuliert die Außensicht eines Angreifers. Für Runtime-Detection in Produktion ist Falco der Standard — das ist aber ein eigenes Projekt, kein Quick-Check.

Absicherung: Die zwei YAML-Manifeste mit dem größten Hebel

Zwei Maßnahmen schließen die Netzwerk- und die Workload-Fläche mit minimalem Aufwand.

NetworkPolicy: default-deny pro Namespace

Ohne NetworkPolicy ist Ihr Pod-Netz flach. Die Basis-Härtung ist eine Default-Deny-Policy für Ingress und Egress pro Namespace:

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

Danach schalten Sie explizit frei, was kommunizieren muss — hier: das API-Deployment darf zur Datenbank auf Port 5432, DNS bleibt erlaubt:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-to-postgres
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

Zwei Stolpersteine: Erstens braucht Ihr CNI NetworkPolicy-Support (Calico, Cilium — Flannel allein kann es nicht; bei AKS/EKS/GKE muss die Policy-Engine beim Cluster-Setup aktiviert sein). Zweitens: Vergessen Sie die DNS-Egress-Regel nicht, sonst löst nach dem Rollout kein Pod mehr Namen auf — der Klassiker.

Pod Security Standards: restricted erzwingen

Seit Kubernetes 1.25 ersetzt der eingebaute Pod Security Admission Controller die alten PodSecurityPolicies. Sie aktivieren ihn per Namespace-Label — kein Zusatz-Tool nötig:

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

Damit ein Deployment unter restricted startet, braucht es einen sauberen SecurityContext:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: api
      image: registry.example.com/api:1.4.2
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

Praxis-Tipp: Setzen Sie zuerst nur warn und audit und beobachten Sie eine Woche lang die Warnungen (kubectl get events), bevor Sie enforce scharf schalten. Sonst blockieren Sie beim nächsten Rollout Workloads, die noch nicht angepasst sind.

Die 12-Punkte-Härtungs-Checkliste

Diese Liste ist so formuliert, dass Sie sie einem Auditor als Nachweis vorlegen können. Jeder Punkt ist prüfbar.

Realistischer Aufwand für einen bestehenden Cluster mittlerer Größe: Punkte 1 bis 6 in ein bis zwei Arbeitstagen, Punkte 7 bis 12 je nach CI/CD-Reife ein bis zwei Wochen nebenher (Schätzung aus Projekterfahrung, stark abhängig von Legacy-Workloads).

Fallstricke aus der Praxis

Secrets im Klartext an drei Orten. Base64 ist keine Verschlüsselung. Typische Fundorte: Secrets als ENV-Variablen im Deployment-Manifest (landen im Git-Repo), in ConfigMaps ("war nur temporär") und in etcd-Backups, die unverschlüsselt im Object Storage liegen. Letzteres übersehen fast alle.

Der latest-Tag. Wer image: foo:latest deployt, weiß nicht, was läuft, und kann nicht nachweisen, was zum Zeitpunkt X lief. Für ein Audit ist das ein direkter Befund. Feste Tags oder Digests, immer.

Offene kubelet- und Dashboard-Ports. Der kubelet-Read-Only-Port 10255 liefert ohne Authentifizierung Pod-Specs samt ENV-Variablen. Das alte Kubernetes-Dashboard mit cluster-admin-Binding war der Einstiegspunkt beim Tesla-Cryptomining-Vorfall 2018 — das Muster existiert bis heute in Bestandsclustern. Prüfen von außen: kube-hunter --remote <node-ip>.

Managed heißt nicht fertig. AKS, EKS und GKE härten die Control Plane — RBAC-Design, NetworkPolicies, Pod Security, Image-Hygiene und Secrets-Management bleiben zu 100 Prozent bei Ihnen. Das Shared-Responsibility-Modell wird in Audits regelmäßig falsch eingeschätzt.

Einmal härten reicht nicht. Jedes neue Deployment, jeder neue Namespace kann den Stand wieder aufweichen. Ohne Admission-Controls (PSS enforce, Kyverno/OPA) und wiederkehrende Scans driftet der Cluster zurück.

FAQ

Gilt der Check auch für Managed Kubernetes (AKS/EKS/GKE)? Ja, mit reduziertem Scope. Die CIS-Sektionen zur Control Plane entfallen (kube-bench bringt eigene Profile für EKS/AKS/GKE mit), alles ab Workload-Ebene — RBAC, NetworkPolicies, Pod Security, Images, Secrets — ist identisch und liegt in Ihrer Verantwortung.

Wie oft sollte ich den Security-Check wiederholen? kube-bench und Trivy gehören als wiederkehrender Job in den Cluster bzw. in die CI-Pipeline (täglich bis wöchentlich). Den vollständigen manuellen Check inklusive RBAC-Review empfehlen wir quartalsweise und zusätzlich nach jedem größeren Kubernetes-Upgrade.

Reichen die drei Tools für ein ISO-27001- oder TISAX-Audit? Sie liefern die technische Evidenz für die Container-Ebene — das ist ein Baustein, kein vollständiger Nachweis. Ein Audit verlangt zusätzlich Prozesse: Patch-Management, Zugriffskontrolle, Incident Response. Die 12-Punkte-Liste oben ist als technischer Nachweis-Anker gedacht, den Sie in Ihr ISMS einhängen.

Was kostet ein professioneller Kubernetes-Security-Check? Die Open-Source-Tools sind kostenlos, kosten aber Ihre Zeit für Interpretation und Priorisierung. Externe Kubernetes-Security-Assessments liegen in Deutschland grob zwischen 5.000 und 20.000 Euro je nach Cluster-Anzahl und Tiefe (Marktschätzung, keine Preisliste). Ein erster strukturierter Befund geht auch kostenlos — siehe Fazit.

Muss ich für NetworkPolicies mein CNI wechseln? Nur wenn Ihr aktuelles CNI keine Policies unterstützt. Flannel pur kann es nicht; Calico, Cilium und die Managed-Varianten (Azure CNI mit Policy-Option, EKS mit VPC-CNI-Policies oder Calico-Add-on, GKE Dataplane V2) können es. Der Wechsel ist auf Bestandsclustern aufwendig — prüfen Sie das vor der Policy-Planung mit kubectl get pods -n kube-system.

Fazit

Einen Kubernetes-Cluster abzusichern ist kein Forschungsprojekt: Sechs Angriffsflächen, drei kostenlose Tools für den Ist-Zustand, zwei YAML-Muster mit großem Hebel und zwölf prüfbare Härtungspunkte. Der Unterschied zwischen einem offenen und einem auditfesten Cluster liegt selten am Budget, sondern daran, ob jemand die Defaults systematisch abarbeitet — und den Stand danach gegen Drift verteidigt.

Wenn Sie wissen wollen, wo Ihr Cluster heute steht, ohne selbst drei Tools auszurollen und die Findings zu priorisieren: Machen Sie den kostenlosen Kubernetes Security Quick-Check. Sie bekommen eine strukturierte Ersteinschätzung entlang der sechs Angriffsflächen — als Grundlage für Ihre interne Härtung oder für das nächste Kundenaudit.