Kubernetes nach BSI IT-Grundschutz absichern

TL;DR

• Der BSI IT-Grundschutz liefert mit den Bausteinen CON.1 (Container), APP.4.4 (Kubernetes) und OPS.1.1 (Server) einen konkreten Anforderungskatalog fuer Kubernetes-Cluster.
• Die meisten Anforderungen lassen sich mit Policy-as-Code (Kyverno oder OPA Gatekeeper) automatisiert durchsetzen, statt manuell zu pruefen.
• RBAC, Network Policies und Pod Security Standards sind die drei Stellschrauben mit dem groessten Effekt bei geringstem Aufwand.
• Image Signing und ein externer Secrets-Store (Vault, External Secrets Operator) decken die Anforderungen an Integritaet und Vertraulichkeit ab.
• Ein iterativer Ansatz -- erst Audit-Modus, dann Enforce -- verhindert Betriebsstoerungen bei der Einfuehrung.

Welche BSI-Bausteine betreffen Kubernetes?

Der BSI IT-Grundschutz ist modular aufgebaut. Nicht alle Bausteine sind fuer jeden Cluster relevant. Die folgende Tabelle zeigt die wichtigsten Bausteine und ihre Zuordnung zu konkreten Kubernetes-Konzepten.

Die Anforderungen in APP.4.4 sind seit 2023 explizit auf Kubernetes zugeschnitten. Wer bereits nach CIS Kubernetes Benchmark haertet, deckt circa 70 Prozent der technischen Anforderungen ab. Die organisatorischen Anforderungen (Rollen, Prozesse, Dokumentation) muessen separat adressiert werden.

Pod Security Standards als Fundament

Seit Kubernetes 1.25 sind Pod Security Standards (PSS) stabil. Sie ersetzen die alten PodSecurityPolicies und bieten drei Profile: Privileged, Baseline und Restricted. Fuer BSI-Konformitaet sollte mindestens das Baseline-Profil enforced werden, auf Namespaces mit sensiblen Workloads das Restricted-Profil.

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

Dieses Label-Set sorgt dafuer, dass Pods im Namespace production nur erstellt werden koennen, wenn sie alle Restricted-Anforderungen erfuellen: kein Root, kein privilegierter Modus, keine Host-Namespaces, read-only Root-Filesystem und definierte Seccomp-Profile.

Policy-as-Code mit Kyverno

Pod Security Standards decken die Grundlagen ab, aber der BSI-Grundschutz verlangt mehr: Image-Herkunft pruefen, Labels erzwingen, Resource Limits setzen. Hier kommt eine Policy Engine ins Spiel. Das folgende Beispiel nutzt Kyverno, weil es nativ mit Kubernetes-Ressourcen arbeitet und keine eigene Sprache erfordert.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-from-trusted-registry
spec:
  validationFailureAction: Audit
  background: true
  rules:
    - name: check-image-registry
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: >-
          Images duerfen nur aus der internen Registry stammen.
          Gefunden: {{ "{{request.object.spec.containers[].image}}" }}
        pattern:
          spec:
            containers:
              - image: "registry.internal.example.com/*"
    - name: require-resource-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Alle Container muessen CPU- und Memory-Limits definieren."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"

Der Ablauf in der Praxis:

1. Policy mit validationFailureAction: Audit deployen.
2. Kyverno Policy Reports auswerten (welche bestehenden Workloads verstoessen?).
3. Verstoesse beheben.
4. Auf Enforce umstellen.

Dieser zweistufige Ansatz ist entscheidend. Wer direkt auf Enforce schaltet, riskiert, dass bestehende Deployments nicht mehr skalieren koennen.

RBAC richtig aufsetzen

Role-Based Access Control ist die Antwort auf den BSI-Baustein ORP.4 (Identitaets- und Berechtigungsmanagement). Die haeufigsten Fehler:

• ClusterRoleBindings auf cluster-admin fuer Entwickler-Accounts
• ServiceAccounts mit Default-Token, die nie rotiert werden
• Kein Scoping auf Namespaces

Eine saubere RBAC-Struktur trennt mindestens drei Ebenen:

Seit Kubernetes 1.24 werden keine automatischen Secret-Tokens fuer ServiceAccounts mehr erstellt. Nutzen Sie stattdessen kurzlebige Token via TokenRequest API oder Projected Volumes. Das reduziert das Risiko, dass ein kompromittierter Pod dauerhaft API-Zugriff hat.

Network Policies: Segmentierung im Cluster

Der BSI-Baustein NET.1.1 fordert Netzwerksegmentierung. In Kubernetes bedeutet das: Network Policies. Ohne explizite Policies ist jeder Pod von jedem anderen Pod erreichbar -- das ist der Default.

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

Diese Default-Deny-Policy blockiert saemtlichen Traffic in und aus dem Namespace production. Von dort aus oeffnen Sie gezielt einzelne Verbindungen:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Wichtig: Network Policies werden nur wirksam, wenn das CNI-Plugin sie unterstuetzt. Calico, Cilium und Antrea koennen das. Flannel kann es nicht.

Hardening-Script fuer die Schnellanalyse

Das folgende Bash-Skript prueft die wichtigsten Hardening-Punkte eines Clusters und gibt eine schnelle Uebersicht, wo Handlungsbedarf besteht.

#!/usr/bin/env bash
set -euo pipefail

echo "=== Kubernetes BSI Hardening Quick-Check ==="
echo ""

echo "[1] Kubernetes-Version:"
kubectl version --short 2>/dev/null || kubectl version --client

echo ""
echo "[2] Namespaces ohne Pod Security Labels:"
kubectl get namespaces -o json | \
  jq -r '.items[] |
    select(.metadata.labels["pod-security.kubernetes.io/enforce"] == null) |
    .metadata.name'

echo ""
echo "[3] Pods mit Root-Rechten:"
kubectl get pods -A -o json | \
  jq -r '.items[] |
    select(.spec.containers[]?.securityContext?.runAsNonRoot != true) |
    "\(.metadata.namespace)/\(.metadata.name)"' | sort -u | head -20

echo ""
echo "[4] Namespaces ohne Default-Deny NetworkPolicy:"
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  policies=$(kubectl get networkpolicy -n "$ns" -o json 2>/dev/null | \
    jq '[.items[] | select(.spec.podSelector == {})] | length')
  if [ "$policies" -eq 0 ]; then
    echo "  MISSING: $ns"
  fi
done

echo ""
echo "[5] ClusterRoleBindings auf cluster-admin (nicht system-intern):"
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] |
    select(.roleRef.name == "cluster-admin") |
    select(.metadata.name | startswith("system:") | not) |
    .metadata.name'

echo ""
echo "[6] API-Server Audit-Policy vorhanden:"
kubectl get pods -n kube-system -l component=kube-apiserver -o json | \
  jq -r '.items[0].spec.containers[0].command[]' | \
  grep -q "audit-policy-file" && echo "  OK" || echo "  NICHT KONFIGURIERT"

echo ""
echo "=== Check abgeschlossen ==="

Dieses Skript ersetzt kein Audit, aber es zeigt in unter einer Minute die groessten Luecken. Es laesst sich gut in eine CI-Pipeline einbinden, um Regressionen zu erkennen.

Secrets Management und Verschluesselung

Der BSI-Baustein CRY.1 verlangt den sicheren Umgang mit kryptografischem Material. Kubernetes Secrets sind base64-kodiert, nicht verschluesselt. Zwei Ansaetze loesen das Problem:

Variante 1: Encryption at Rest im etcd

In der API-Server-Konfiguration wird eine EncryptionConfiguration hinterlegt, die Secrets mit AES-CBC oder AES-GCM verschluesselt, bevor sie in etcd geschrieben werden. Das schuetzt gegen direkten etcd-Zugriff, aber nicht gegen API-Zugriff.

Variante 2: External Secrets Operator + Vault

Secrets werden in HashiCorp Vault oder einem Cloud KMS gespeichert. Der External Secrets Operator synchronisiert sie als Kubernetes Secrets in den Cluster. Der Vorteil: Zentrale Verwaltung, Audit-Trail, automatische Rotation. Der Nachteil: Eine zusaetzliche Komponente, die selbst abgesichert werden muss.

Fuer BSI-Konformitaet empfehle ich Variante 2 in Kombination mit Variante 1. Encryption at Rest als Baseline, Vault fuer alles, was rotiert oder auditiert werden muss.

Audit Logging konfigurieren

Ohne Audit Logs ist eine Sicherheitsbewertung nach BSI-Grundschutz nicht moeglich. Der API-Server muss so konfiguriert werden, dass mindestens Metadata-Level geloggt wird. Fuer sensitive Ressourcen (Secrets, RBAC-Aenderungen) ist RequestResponse-Level angemessen.

Die Logs sollten nicht lokal auf dem Control-Plane-Node verbleiben, sondern in ein zentrales Log-System (Loki, Elasticsearch, Splunk) fliessen. Dort koennen sie mit Regeln korreliert werden, etwa: "ServiceAccount X hat zum ersten Mal Secrets im Namespace Y gelesen."

Falco ergaenzt das API-Audit-Log durch Runtime-Ueberwachung auf Kernel-Ebene. Es erkennt Aktivitaeten wie Shell-Zugriff in Containern, unerwartete Netzwerkverbindungen oder das Lesen von /etc/shadow.

Iterativer Implementierungsplan

Die vollstaendige BSI-Konformitaet laesst sich nicht in einem Sprint erreichen. Ein realistischer Plan sieht so aus:

Woche 1-2: Bestandsaufnahme

• CIS Benchmark mit kube-bench ausfuehren
• Hardening-Script (siehe oben) laufen lassen
• Bestehende RBAC-Bindings dokumentieren

Woche 3-4: Quick Wins

• Pod Security Standards auf allen Namespaces (Audit-Modus)
• Default-Deny NetworkPolicy in Staging-Namespaces
• Kyverno installieren mit Policies im Audit-Modus

Woche 5-8: Enforcement

• PSS auf Enforce umstellen (Namespace fuer Namespace)
• Kyverno-Policies auf Enforce
• RBAC-Bereinigung: cluster-admin nur fuer Break-Glass-Accounts
• Audit Logging aktivieren und an SIEM anbinden

Woche 9-12: Haertung und Dokumentation

• External Secrets Operator einrichten
• Falco deployen und Baseline-Regeln konfigurieren
• Network Policies fuer alle Produktions-Namespaces
• BSI-Dokumentation erstellen (Schutzbedarf, Modellierung, Risikoanalyse)

Nach 12 Wochen haben Sie eine solide Grundlage. Die BSI-Dokumentation (Strukturanalyse, Schutzbedarfsfeststellung, Modellierung) ist ein separater Aufwand, der parallel laufen sollte.

Haeufige Fehler bei der Umsetzung

Zu viele Policies auf einmal. Wer 50 Kyverno-Policies gleichzeitig auf Enforce schaltet, wird mit Tickets ueberschwemmt. Besser: 5 Policies pro Sprint, immer mit Audit-Phase.

Network Policies ohne Egress. Viele Teams setzen nur Ingress-Policies. Aber ein kompromittierter Pod, der beliebig nach aussen kommunizieren kann, ist ein Problem. Egress-Policies sind aufwaendiger (DNS muss erlaubt werden), aber fuer BSI-Konformitaet noetig.

RBAC-Wildcard-Permissions. resources: ["*"] und verbs: ["*"] in einer ClusterRole sind ein Audit-Killer. Jede Permission sollte explizit benannt sein.

Kein Monitoring der Security-Tools. Kyverno, Falco und der External Secrets Operator muessen selbst ueberwacht werden. Wenn Kyverno ausfaellt, werden keine Policies mehr enforced -- und niemand merkt es.

Weiterführende Ressourcen

Wenn Sie tiefer in einzelne Aspekte einsteigen wollen:

• Kubernetes Network Policies im Detail behandelt fortgeschrittene Netzwerksegmentierung mit Cilium.
• RBAC fuer Enterprise-Umgebungen zeigt RBAC-Patterns fuer groessere Teams mit mehreren Clustern.
• Kubernetes Security Scanning Tools im Vergleich vergleicht Trivy, Grype und Snyk fuer Image-Scans.
• Secrets Management mit Vault ist ein Deep-Dive in die Vault-Integration.
• Audit Logging einrichten erklaert die API-Server-Konfiguration Schritt fuer Schritt.

Sie planen die Absicherung Ihres Kubernetes-Clusters nach BSI IT-Grundschutz und suchen Unterstuetzung bei der Umsetzung? Wir helfen bei der Gap-Analyse, Policy-Implementierung und Audit-Vorbereitung. Sprechen Sie uns an unter /kontakt.