Kubernetes KRITIS: Container-Sicherheit fuer kritische Infrastrukturen

TL;DR

• KRITIS-Betreiber (Energie, Wasser, Gesundheit, Finanz, Transport, IT/TK, Ernaehrung) muessen seit NIS2 erhoehte Sicherheitsanforderungen fuer alle IT-Systeme einhalten -- Kubernetes-Cluster eingeschlossen
• BSI-Anforderungen umfassen Netzwerksegmentierung, Verschluesselung, Zugriffskontrollen, Audit-Logging, Incident Reporting und regelmaessige Sicherheitspruefungen
• Sektorspezifische Vorgaben (z.B. BAIT fuer Finanz, B3S fuer Gesundheit) definieren zusaetzliche Anforderungen an Container-Plattformen
• Meldepflichten erfordern automatisierte Incident Detection und strukturierte Meldeketten -- bei erheblichen Stoerungen innerhalb von 24 Stunden an das BSI
• Audit Trails muessen lueckenlos, manipulationssicher und mindestens 12 Monate aufbewahrt werden

KRITIS und Kubernetes: Warum das Thema jetzt kritisch ist

Die KRITIS-Verordnung und die europaeische NIS2-Richtlinie verpflichten Betreiber kritischer Infrastrukturen zu erhoehten IT-Sicherheitsstandards. Mit der zunehmenden Containerisierung in KRITIS-Sektoren -- von der Energieversorgung ueber das Gesundheitswesen bis zum Finanzsektor -- rueckt Kubernetes in den Fokus der Regulierung.

Das Problem: Kubernetes wurde als Plattform fuer schnelle Entwicklung und Skalierung entworfen -- nicht primaer fuer hochregulierte Umgebungen. Die Standard-Konfiguration erfuellt keine einzige KRITIS-Anforderung. Betreiber muessen ihre Cluster gezielt haerten, ueberwachen und dokumentieren.

Welche Sektoren sind betroffen?

BSI-Anforderungen an Kubernetes-Cluster

Das BSI (Bundesamt fuer Sicherheit in der Informationstechnik) definiert ueber den IT-Grundschutz und die KRITIS-Verordnung konkrete Anforderungen, die sich direkt auf Kubernetes-Cluster uebertragen lassen.

Anforderung 1: Netzwerksegmentierung und Zugangskontrolle

KRITIS-Systeme muessen netzwerktechnisch segmentiert und der Zugang streng kontrolliert werden.

# Default-Deny NetworkPolicy fuer KRITIS-Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kritis-default-deny
  namespace: kritis-production
  labels:
    compliance: kritis
    bsi-control: NET.1.1
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Nur erlaubte Kommunikation zum SCADA-Gateway
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-scada-gateway
  namespace: kritis-production
  labels:
    compliance: kritis
    bsi-control: NET.1.1
spec:
  podSelector:
    matchLabels:
      app: scada-connector
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.100.0.0/24
      ports:
        - protocol: TCP
          port: 502

RBAC fuer KRITIS-Namespaces sollte ausschliesslich Read-Only-Rechte vergeben. Schreiboperationen erfolgen nur ueber die GitOps-Pipeline (ArgoCD/Flux), niemals direkt durch Operatoren. Jede Rolle wird auf einen einzelnen Namespace beschraenkt.

Detaillierte RBAC-Strategien finden Sie in unserem Beitrag zu Kubernetes RBAC fuer Enterprise.

Anforderung 2: Verschluesselung und Secrets Management

KRITIS verlangt Verschluesselung fuer Daten in Transit und at Rest.

# EncryptionConfiguration fuer etcd (Secrets at Rest)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aescbc:
          keys:
            - name: kritis-key-2026
              secret: BASE64_ENCODED_32_BYTE_KEY
      - identity: {}

# Istio PeerAuthentication: mTLS fuer KRITIS-Namespaces
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: kritis-mtls-strict
  namespace: kritis-production
spec:
  mtls:
    mode: STRICT

Anforderung 3: Audit-Logging und Nachvollziehbarkeit

Fuer KRITIS-Betreiber ist ein lueckenloses Audit-Logging nicht optional, sondern Pflicht. Jede Aenderung an der Infrastruktur muss nachvollziehbar sein.

Die Audit Policy muss mindestens diese Bereiche auf RequestResponse-Level loggen:

• Secrets und ConfigMaps im KRITIS-Namespace
• RBAC-Aenderungen (Roles, RoleBindings, ClusterRoles, ClusterRoleBindings)
• Workload-Aenderungen (Deployments, StatefulSets, DaemonSets)
• Alle Schreiboperationen auf Metadata-Level

# Pruefen, ob Audit-Logging konfiguriert ist
kubectl get pods -n kube-system -l component=kube-apiserver -o json | \
  jq -r '.items[].spec.containers[].command[]' | \
  grep -E "audit-log|audit-policy"

Anforderung 4: Schwachstellen-Management

KRITIS-Betreiber muessen bekannte Schwachstellen zeitnah beheben. Fuer Kubernetes bedeutet das: kontinuierliches Image-Scanning und Patch-Management.

# Trivy-Scan aller Images im KRITIS-Namespace
for image in $(kubectl get pods -n kritis-production -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | sort -u); do
  echo "=== Scanning: $image ==="
  trivy image --severity HIGH,CRITICAL --exit-code 1 "$image"
done

# Kubescape-Scan speziell fuer KRITIS-relevante Controls
kubescape scan framework cis-v1.23-t1.0.1 \
  --include-namespaces kritis-production \
  --format json \
  --output kritis-scan-$(date +%Y%m%d).json

Mehr zu automatisiertem Security Scanning finden Sie unter Kubernetes Security Scanning.

Sektorspezifische Anforderungen

Energiesektor: IT-Sicherheitskatalog der BNetzA

Energieversorger muessen den IT-Sicherheitskatalog der Bundesnetzagentur (BNetzA) einhalten, der auf ISO 27001 und ISO 27019 basiert.

Kubernetes-spezifische Anforderungen:

• Trennung von IT und OT (Operational Technology) auf Cluster-Ebene
• Dedizierte Cluster fuer SCADA-nahe Systeme, keine Shared Infrastructure
• Netzwerk-Isolation zwischen Leitstellen-Anbindung und Standard-IT
• Verschluesselung aller Daten, die das Prozessleitsystem verlassen

# Namespace-Labels fuer OT/IT-Trennung
apiVersion: v1
kind: Namespace
metadata:
  name: kritis-ot
  labels:
    sector: energy
    zone: operational-technology
    isolation-level: critical
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

Gesundheitssektor: B3S und Patientendaten

Der branchenspezifische Sicherheitsstandard (B3S) fuer die Gesundheitsversorgung definiert Anforderungen, die ueber den allgemeinen IT-Grundschutz hinausgehen.

Kubernetes-spezifische Anforderungen:

• Strikte Mandantentrennung fuer Patientendaten (Paragraph 203 StGB)
• Pseudonymisierung personenbezogener Daten im Cluster
• Hoechste Verfuegbarkeitsanforderungen fuer klinische Systeme
• Dokumentation aller Datenverarbeitungstaetigkeiten

Pods im Gesundheitssektor muessen mit runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false und capabilities.drop: ALL konfiguriert sein. Labels wie data-classification: patient-data und b3s-compliance: required ermoeglichen die automatisierte Policy-Pruefung.

Finanzsektor: BAIT und MaRisk

Die Bankaufsichtlichen Anforderungen an die IT (BAIT) und die Mindestanforderungen an das Risikomanagement (MaRisk) stellen hohe Anforderungen an Container-Plattformen im Finanzsektor.

Kubernetes-spezifische Anforderungen:

• Change-Management-Prozess fuer jede Cluster-Aenderung
• 4-Augen-Prinzip fuer Deployments in Produktion
• Lueckenlose Protokollierung aller Transaktionsverarbeitungen
• Regelmaessige Penetrationstests und Schwachstellenanalysen
• Business Continuity: RPO und RTO muessen definiert und getestet sein

# Kyverno Policy: 4-Augen-Prinzip erzwingen
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-approval-annotation
  annotations:
    policies.kyverno.io/description: >-
      Deployments im KRITIS-Finanz-Namespace muessen eine
      Approval-Annotation mit zweitem Approver enthalten.
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: require-dual-approval
      match:
        any:
          - resources:
              kinds:
                - Deployment
              namespaces:
                - kritis-finance
      validate:
        message: "Deployment benoetigt approval/reviewer-1 und approval/reviewer-2 Annotations"
        pattern:
          metadata:
            annotations:
              approval/reviewer-1: "?*"
              approval/reviewer-2: "?*"

Incident Reporting: Meldepflichten einhalten

KRITIS-Betreiber muessen erhebliche Stoerungen an das BSI melden. Die Fristen sind streng:

Automatisierte Incident Detection

# Falco-Regeln fuer KRITIS-relevante Events
- rule: KRITIS Unauthorized Secret Access
  desc: Nicht autorisierter Zugriff auf Secrets im KRITIS-Namespace
  condition: >
    ka.verb in (get, list) and
    ka.target.resource = "secrets" and
    ka.target.namespace = "kritis-production" and
    not ka.user.name in (kritis-approved-users)
  output: >
    KRITIS ALERT: Unautorisierter Secret-Zugriff
    (user=%ka.user.name resource=%ka.target.name
    namespace=%ka.target.namespace)
  priority: CRITICAL
  tags: [kritis, incident, secrets]

- rule: KRITIS Container Drift
  desc: Neuer Prozess in KRITIS-Container erkannt
  condition: >
    spawned_process and
    container and
    k8s.ns.name = "kritis-production" and
    not proc.name in (allowed_processes)
  output: >
    KRITIS ALERT: Unerwarteter Prozess in Container
    (process=%proc.name container=%container.name
    namespace=%k8s.ns.name pod=%k8s.pod.name)
  priority: CRITICAL
  tags: [kritis, incident, runtime]

Meldekette automatisieren

Die automatisierte Meldekette umfasst vier Schritte: (1) Incident-Ticket erstellen, (2) On-Call-Team via PagerDuty/OpsGenie benachrichtigen, (3) BSI-Meldung vorbereiten (Template), (4) Forensik-Daten sichern (Audit-Logs und Cluster-State). Tools wie Falcosidekick oder AlertManager lassen sich als Trigger konfigurieren.

Details zum Incident-Response-Prozess finden Sie unter Kubernetes Incident Response.

Audit Trails: Manipulationssichere Dokumentation

KRITIS-Audits erfordern lueckenlose und manipulationssichere Audit Trails. Kubernetes-native Audit-Logs allein reichen dafuer nicht aus.

Anforderungen an KRITIS-Audit-Trails

• Vollstaendigkeit: Alle sicherheitsrelevanten Ereignisse erfasst
• Integritaet: Manipulationsschutz durch Signaturen oder Write-Once-Storage
• Aufbewahrung: Mindestens 12 Monate, sektorabhaengig bis zu 10 Jahre
• Verfuegbarkeit: Innerhalb von 24 Stunden fuer Auditoren zugaenglich
• Vertraulichkeit: Zugriff auf Audit-Logs nur fuer autorisierte Personen

Technische Umsetzung

Die empfohlene Architektur: Fluentd oder Fluent Bit sammelt die Kubernetes Audit Logs und sendet sie an einen S3-kompatiblen Object Storage mit Object Lock (Write-Once-Read-Many). Damit sind Logs physisch vor nachtraeglicher Manipulation geschuetzt. Alternativ koennen Logs an ein dediziertes SIEM (Splunk, Elasticsearch) mit Write-Protection weitergeleitet werden.

KRITIS-Compliance-Checkliste fuer Kubernetes

Weitergehende Compliance-Informationen bietet unser Artikel Kubernetes DSGVO und BSI Compliance.

Audit-Vorbereitung: Was KRITIS-Pruefer erwarten

Bei einem KRITIS-Audit durch das BSI oder beauftragte Pruefer werden typischerweise diese Nachweise verlangt:

1. Netzwerkplan: Welche Pods kommunizieren mit welchen externen Systemen? NetworkPolicy-Dokumentation.
2. Berechtigungsmatrix: Wer hat welche Rechte im Cluster? RBAC-Export mit Begruendung.
3. Patch-Historie: Wann wurden welche Updates eingespielt? Image-Tags und Deployment-History.
4. Audit-Logs: Lueckenlose Logs der letzten 12 Monate, schnell durchsuchbar.
5. Incident-Dokumentation: Alle Sicherheitsvorfaelle mit Meldung, Analyse und Massnahmen.
6. Risikobewertung: Dokumentierte Risiken mit Einstufung und Behandlungsplan.
7. Notfallplan: Disaster-Recovery-Verfahren mit dokumentierten Tests.

# RBAC-Export fuer Auditoren generieren
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | "\(.metadata.name): \(.roleRef.name) -> \(.subjects[]?.name) (\(.subjects[]?.kind))"' \
  > rbac-export-$(date +%Y%m%d).txt

Fazit

Kubernetes in KRITIS-Umgebungen zu betreiben erfordert einen systematischen Ansatz, der weit ueber Standard-Security-Hardening hinausgeht. Die Kombination aus Netzwerksegmentierung, strikter Zugriffskontrolle, lueckenlosem Audit-Logging, automatisierter Incident Detection und sektorspezifischen Anforderungen macht KRITIS-Compliance zu einer anspruchsvollen Aufgabe.

Der Schluessel zum Erfolg liegt in der Automatisierung: Manuelle Prozesse skalieren nicht und sind fehleranfaellig. Policy-as-Code, Continuous Scanning und automatisierte Meldeketten stellen sicher, dass Compliance nicht nur zum Audit-Zeitpunkt, sondern dauerhaft gegeben ist.

Verwandte Artikel

• Kubernetes Security Hardening: Die komplette Checkliste
• Kubernetes DSGVO und BSI Compliance
• Kubernetes Security Scanning automatisiert
• Kubernetes Security Audit: Was Unternehmen pruefen lassen sollten
• Kubernetes Incident Response

Sie betreiben Kubernetes in einer KRITIS-Umgebung und benoetigen Unterstuetzung bei der Compliance? Wir beraten Sie zu BSI-Anforderungen, sektorspezifischen Vorgaben und der technischen Umsetzung. Kontaktieren Sie uns unter /kontakt.