BSI-Grundschutz für Kubernetes-Cluster umsetzen

TL;DR

Der BSI-Baustein SYS.1.6 (Containerisierung) definiert verbindliche Anforderungen für Kubernetes-Cluster in deutschen Behörden und KRITIS-Unternehmen. Die Umsetzung erfordert Pod Security Standards im Restricted-Modus, Audit-Logging auf API-Server-Ebene, Netzwerksegmentierung per Network Policies und dokumentierte Härtungsmaßnahmen. Dieser Guide mappt jede BSI-Anforderung auf konkrete Kubernetes-Konfigurationen.

Der BSI IT-Grundschutz ist für Bundesbehörden verpflichtend und für KRITIS-Betreiber der De-facto-Standard. Mit dem Baustein SYS.1.6 Containerisierung hat das BSI 2022 spezifische Anforderungen für Container-Plattformen veröffentlicht. Wer Kubernetes betreibt, muss diese Anforderungen technisch umsetzen und dokumentieren.

# Schnellcheck: Wie steht Ihr Cluster da?
# kube-bench prüft CIS-Benchmark-Konformität
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

BSI SYS.1.6: Die relevanten Anforderungen

Der Baustein SYS.1.6 gliedert sich in Basis-, Standard- und erhöhte Anforderungen. Nicht jede Anforderung betrifft Kubernetes direkt - die folgende Tabelle zeigt das Mapping auf Cluster-Konfigurationen.

SYS.1.6.A5 umsetzen: Minimale Rechte

Die BSI-Anforderung A5 verlangt, dass Container nur mit den minimal notwendigen Rechten laufen. In Kubernetes bedeutet das: Pod Security Standards im Restricted-Modus erzwingen.

# Namespace mit BSI-konformer Pod Security konfigurieren
apiVersion: v1
kind: Namespace
metadata:
  name: bsi-compliant-workloads
  labels:
    # Restricted-Modus erzwingen - keine Ausnahmen
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    # Audit-Modus für Monitoring
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
  annotations:
    bsi.grundschutz/baustein: "SYS.1.6"
    bsi.grundschutz/anforderung: "A5"
---
# BSI-konformes Deployment-Template
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bsi-compliant-app
  namespace: bsi-compliant-workloads
spec:
  replicas: 2
  selector:
    matchLabels:
      app: bsi-compliant-app
  template:
    metadata:
      labels:
        app: bsi-compliant-app
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
        fsGroup: 65534
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          image: registry.example.com/app:1.4.2
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ['ALL']
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi

SYS.1.6.A6: Netzwerksegmentierung

Das BSI fordert, dass Container-Netzwerke segmentiert werden. Ohne Network Policies kommuniziert jeder Pod mit jedem - ein klarer Verstoß gegen SYS.1.6.A6.

Die Umsetzung folgt dem Default-Deny-Prinzip:

# Schritt 1: Default-Deny für den gesamten Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: bsi-compliant-workloads
  annotations:
    bsi.grundschutz/anforderung: "A6"
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Schritt 2: Nur explizit erlaubte Kommunikation
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-ingress
  namespace: bsi-compliant-workloads
spec:
  podSelector:
    matchLabels:
      app: bsi-compliant-app
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - namespaceSelector: {}
      ports:
        - protocol: UDP
          port: 53
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432

SYS.1.6.A8: Audit-Logging konfigurieren

Ohne Audit-Logging können Sie nicht nachweisen, wer wann welche Änderungen am Cluster vorgenommen hat. Das BSI verlangt eine nachvollziehbare Protokollierung.

# /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Sicherheitsrelevante Ressourcen vollständig loggen
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets", "serviceaccounts"]
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
  # Workload-Änderungen loggen
  - level: Request
    resources:
      - group: ""
        resources: ["pods", "namespaces"]
      - group: "apps"
        resources: ["deployments", "statefulsets", "daemonsets"]
    verbs: ["create", "update", "patch", "delete"]
  # Lesezugriffe nur Metadaten
  - level: Metadata
    verbs: ["get", "list", "watch"]
  # Health-Checks ignorieren
  - level: None
    nonResourceURLs: ["/healthz*", "/readyz*", "/livez*"]

Den API-Server starten Sie mit den Flags --audit-policy-file=/etc/kubernetes/audit-policy.yaml und --audit-log-path=/var/log/kubernetes/audit.log. Leiten Sie die Logs an ein zentrales SIEM weiter, um die BSI-Anforderung an Aufbewahrungsfristen zu erfüllen.

BSI-Compliance-Checkliste für Kubernetes

Basis-Anforderungen (verpflichtend)

• Container-Einsatz dokumentiert und genehmigt (A1)
• Nur geprüfte und signierte Images aus internem Registry (A3)
• Pod Security Standards auf restricted (A5)
• Default-Deny NetworkPolicies in allen Namespaces (A6)
• Audit-Logging aktiviert und SIEM-Anbindung (A8)

Standard-Anforderungen

• etcd Encryption at Rest konfiguriert (A9)
• Automatisiertes Image-Scanning in CI/CD (A3)
• RBAC mit Least-Privilege-Prinzip dokumentiert (A5)
• Regelmäßige kube-bench CIS-Benchmark-Prüfung
• Runtime-Monitoring mit Falco oder vergleichbar (A11)

Erhöhte Anforderungen

• Regelmäßige Penetrationstests durch externen Dienstleister (A13)
• Service Mesh mit mTLS für Pod-zu-Pod-Verschlüsselung
• Automatisierte Compliance-Checks per OPA/Gatekeeper

Häufige Fehler bei der BSI-Umsetzung

Drei Probleme sehe ich in der Praxis immer wieder:

1. Nur Technik, keine Dokumentation. Das BSI verlangt nicht nur technische Maßnahmen, sondern deren Dokumentation. Annotieren Sie Ihre Kubernetes-Ressourcen mit BSI-Referenzen (wie in den YAML-Beispielen oben) und pflegen Sie ein Sicherheitskonzept.

2. Namespace-Wildwuchs ohne Governance. Jeder Namespace braucht Pod Security Labels und NetworkPolicies. Erzwingen Sie das per Admission Controller (Kyverno oder OPA/Gatekeeper), damit neue Namespaces automatisch BSI-konform sind.

3. Audit-Logs ohne Auswertung. Logs zu schreiben ist Pflicht - aber ohne Alerting auf Security-Events bringt das wenig. Definieren Sie konkrete Alert-Regeln für fehlgeschlagene Authentifizierungen, Secrets-Zugriffe und RBAC-Änderungen.

FAQ

Ist BSI IT-Grundschutz für mein Unternehmen verpflichtend?

Für Bundesbehörden ja. Für KRITIS-Betreiber ist der Grundschutz der empfohlene Rahmen zum Nachweis angemessener IT-Sicherheit nach dem BSI-Gesetz. Privatunternehmen können ihn freiwillig als Best Practice nutzen.

Welcher BSI-Baustein gilt für Kubernetes?

Primär SYS.1.6 (Containerisierung). Zusätzlich relevant sind SYS.1.1 (Allgemeiner Server), NET.1.1 (Netzarchitektur) und OPS.1.1.3 (Patch- und Änderungsmanagement).

Kann ich BSI-Compliance automatisiert prüfen?

Teilweise. Tools wie kube-bench (CIS-Benchmark), kubescape (NSA/MITRE-Checks) und OPA/Gatekeeper (Policy-Enforcement) decken die technischen Anforderungen ab. Die organisatorischen Anforderungen (Dokumentation, Prozesse) müssen manuell geprüft werden.

Wie unterscheidet sich BSI-Grundschutz von ISO 27001?

BSI IT-Grundschutz ist deutlich konkreter als ISO 27001 und gibt spezifische technische Maßnahmen vor. Ein BSI-Grundschutz-Zertifikat beinhaltet automatisch eine ISO 27001-Konformität (ISO 27001 auf Basis von IT-Grundschutz).