CIS Benchmark: Kubernetes-Cluster systematisch härten

TL;DR

Der CIS Kubernetes Benchmark definiert über 120 Prüfpunkte für sichere Cluster-Konfiguration. Mit kube-bench scannen Sie Ihren Cluster automatisiert gegen diese Vorgaben. Die kritischsten Findings betreffen API-Server-Authentifizierung, etcd-Verschlüsselung und Kubelet-Absicherung. Dieser Guide zeigt Installation, Scan-Durchführung und Remediation für die häufigsten Failures.

Der CIS (Center for Internet Security) Kubernetes Benchmark ist der De-facto-Standard für Cluster-Härtung. Auditor:innen, Compliance-Teams und Security-Scanner referenzieren ihn. Trotzdem scheitern die meisten Cluster an grundlegenden Prüfpunkten -- nicht aus Nachlässigkeit, sondern weil die Standardkonfiguration vieler Distributionen schlicht nicht CIS-konform ist.

kube-bench installieren und ausführen

kube-bench ist das Open-Source-Tool von Aqua Security, das CIS-Benchmark-Checks automatisiert durchführt. Die schnellste Methode ist ein Job direkt im Cluster:

apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
  namespace: kube-system
spec:
  template:
    spec:
      hostPID: true
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
          effect: NoSchedule
      containers:
        - name: kube-bench
          image: aquasec/kube-bench:v0.8.0
          command: ["kube-bench", "run", "--targets", "master"]
          volumeMounts:
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
            - name: etc-systemd
              mountPath: /etc/systemd
              readOnly: true
      restartPolicy: Never
      volumes:
        - name: var-lib-kubelet
          hostPath:
            path: /var/lib/kubelet
        - name: etc-kubernetes
          hostPath:
            path: /etc/kubernetes
        - name: etc-systemd
          hostPath:
            path: /etc/systemd
  backoffLimit: 0

Alternativ direkt auf einem Node per Binary:

# kube-bench herunterladen und ausfuehren
curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.8.0/kube-bench_0.8.0_linux_amd64.tar.gz | tar xz
sudo ./kube-bench run --targets master,node,policies

# Nur kritische Failures anzeigen
sudo ./kube-bench run --targets master | grep -A 2 "\[FAIL\]"

# JSON-Output fuer Weiterverarbeitung
sudo ./kube-bench run --json --outputfile results.json

Die Ergebnisse zeigen pro Prüfpunkt den Status: PASS, FAIL, WARN oder INFO. Konzentrieren Sie sich zuerst auf die FAILs.

Die kritischsten CIS-Findings und ihre Remediation

1. API-Server: Authentifizierung und Autorisierung

Die meisten FAIL-Ergebnisse betreffen den API-Server. Hier die häufigsten Findings:

CIS 1.2.1 -- Anonymous Auth deaktivieren:

# /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
    - name: kube-apiserver
      command:
        - kube-apiserver
        ---anonymous-auth=false
        ---authorization-mode=Node,RBAC
        ---enable-admission-plugins=NodeRestriction,PodSecurity
        ---audit-log-path=/var/log/kubernetes/audit.log
        ---audit-log-maxage=30
        ---audit-log-maxbackup=10
        ---audit-log-maxsize=100
        ---profiling=false
        ---request-timeout=300s
        ---service-account-lookup=true
        ---tls-min-version=VersionTLS12

Jedes dieser Flags adressiert einen spezifischen CIS-Check:

2. etcd absichern

etcd speichert den gesamten Cluster-State inklusive Secrets. Ohne Absicherung kann jeder mit Netzwerkzugriff den kompletten Cluster übernehmen.

CIS 2.1 -- Client-Zertifikate für etcd erzwingen:

# /etc/kubernetes/manifests/etcd.yaml (Auszug)
spec:
  containers:
    - name: etcd
      command:
        - etcd
        ---client-cert-auth=true
        ---cert-file=/etc/kubernetes/pki/etcd/server.crt
        ---key-file=/etc/kubernetes/pki/etcd/server.key
        ---trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
        ---peer-client-cert-auth=true
        ---peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
        ---peer-key-file=/etc/kubernetes/pki/etcd/peer.key
        ---peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
        ---auto-tls=false
        ---peer-auto-tls=false

Zusätzlich sollten Sie Encryption at Rest für Secrets aktivieren:

# /etc/kubernetes/enc/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

Den API-Server starten Sie dann mit --encryption-provider-config=/etc/kubernetes/enc/encryption-config.yaml.

3. Kubelet-Konfiguration härten

Der Kubelet ist der Agent auf jedem Node und oft nachlässig konfiguriert.

CIS 4.2.1-4.2.6 -- Kubelet-Flags:

# /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
authorization:
  mode: Webhook
readOnlyPort: 0
protectKernelDefaults: true
eventRecordQPS: 5
rotateCertificates: true
serverTLSBootstrap: true

kube-bench in CI/CD integrieren

Einmalige Scans reichen nicht. Integrieren Sie kube-bench in Ihre Pipeline, damit neue Konfigurationsänderungen nicht die Compliance brechen:

#!/bin/bash
# ci-cis-check.sh -- Exit Code 1 bei kritischen Failures
RESULTS=$(kube-bench run --json 2>/dev/null)
FAIL_COUNT=$(echo "$RESULTS" | jq '[.Controls[].tests[].results[] | select(.status == "FAIL")] | length')

echo "CIS Benchmark: $FAIL_COUNT Failures gefunden"

if [ "$FAIL_COUNT" -gt 0 ]; then
  echo "$RESULTS" | jq -r '.Controls[].tests[].results[] | select(.status == "FAIL") | "\(.test_number): \(.test_desc)"'
  exit 1
fi

echo "Alle CIS-Checks bestanden."
exit 0

Managed Kubernetes: Was der Provider nicht macht

Bei EKS, AKS und GKE betreibt der Cloud-Provider die Control Plane. Die CIS-Checks für API-Server und etcd sind dort nicht anwendbar. Aber die Worker-Node- und Policy-Checks (Abschnitt 4 und 5) liegen in Ihrer Verantwortung.

kube-bench erkennt die Plattform automatisch:

# Auf EKS
kube-bench run --benchmark eks-1.4.0

# Auf GKE
kube-bench run --benchmark gke-1.6.0

# Auf AKS
kube-bench run --benchmark aks-1.5.0

Prüfen Sie bei Managed Kubernetes mindestens: Pod Security Standards, Network Policies, RBAC-Konfiguration und Kubelet-Einstellungen der Node Groups.

Priorisierung: Was zuerst beheben?

Nicht alle 120+ Checks sind gleich kritisch. Diese Reihenfolge hat sich bewährt:

Sofort (Tag 1):

• Anonymous Auth deaktivieren (API-Server + Kubelet)
• etcd-Verschlüsselung für Secrets aktivieren
• Audit-Logging einschalten

Kurzfristig (Woche 1-2):

• RBAC statt ABAC sicherstellen
• Read-Only-Ports deaktivieren
• Profiling-Endpoints abschalten
• Zertifikatsrotation aktivieren

Mittelfristig (Monat 1-2):

• Admission Controller konfigurieren (PodSecurity, NodeRestriction)
• Automatisierte CIS-Scans in CI/CD
• Compliance-Reporting aufsetzen

FAQ

Wie oft sollte ich kube-bench ausführen?

Mindestens wöchentlich automatisiert und nach jeder Änderung an der Cluster-Konfiguration. In regulierten Umgebungen (KRITIS, NIS2) empfiehlt sich ein täglicher Scan mit Alerting bei neuen Failures.

Muss ich alle CIS-Checks bestehen?

Nein. Der CIS Benchmark unterscheidet zwischen Level 1 (Basis-Sicherheit, sollte jeder umsetzen) und Level 2 (erhöhte Sicherheit, kann Funktionalität einschränken). Für die meisten Produktionsumgebungen ist Level 1 vollständig plus ausgewählte Level-2-Checks der richtige Ansatz.

Funktioniert kube-bench mit K3s oder RKE2?

Ja. kube-bench erkennt die Distribution automatisch oder Sie geben sie manuell an: kube-bench run --benchmark rke2-cis-1.7-hardened. K3s und RKE2 von SUSE liefern teilweise bereits CIS-konforme Defaults mit.

Was ist der Unterschied zwischen kube-bench und kubescape?

kube-bench prüft ausschließlich den CIS Kubernetes Benchmark. kubescape deckt zusätzlich NSA/CISA-Hardening-Guidelines und das MITRE ATT&CK-Framework ab. Beide Tools ergänzen sich -- kube-bench für CIS-Compliance, kubescape für eine breitere Sicherheitsbewertung.

Wie dokumentiere ich CIS-Compliance für Audits?

Exportieren Sie kube-bench-Ergebnisse als JSON und archivieren Sie sie mit Zeitstempel. Für jeden FAIL, den Sie bewusst nicht beheben, erstellen Sie eine dokumentierte Risikobewertung mit Begründung. Viele Auditoren akzeptieren das als "Comply or Explain"-Ansatz.