Red/Black Architektur mit Kubernetes umsetzen

TL;DR

• Red/Black trennt klassifizierte (Red) und unklassifizierte (Black) Workloads physisch und logisch voneinander
• Zwei separate Kubernetes-Cluster sind der sicherste Ansatz -- ein Namespace-basierter Split reicht nicht
• Data Diodes erzwingen unidirektionalen Datenfluss auf Hardware-Ebene, kein Software-Workaround kann das ersetzen
• NetworkPolicies innerhalb jedes Clusters begrenzen die laterale Bewegung zusaetzlich
• Der Ansatz stammt aus militaerischen Umgebungen, ist aber fuer jede Organisation mit hohem Schutzbedarf relevant

Was ist eine Red/Black Architektur?

Das Konzept stammt aus der SIGINT- und COMSEC-Welt. "Red" bezeichnet die Seite, auf der Daten im Klartext vorliegen -- also die klassifizierte Zone. "Black" ist die verschluesselte oder unklassifizierte Seite. Die Grenze dazwischen heisst Crypto Boundary.

Uebertragen auf Kubernetes bedeutet das: Zwei vollstaendig getrennte Cluster, die ueber keine gemeinsame Netzwerkinfrastruktur verfuegen. Kein Shared etcd, kein gemeinsamer API-Server, keine Cross-Cluster Service Discovery. Die einzige erlaubte Verbindung ist eine Data Diode, die physikalisch nur in eine Richtung Daten durchlaesst.

Das klingt extrem, und das ist es auch. Aber wenn Workloads Geheimhaltungsstufen wie VS-NfD oder hoeher verarbeiten, fuehrt kein Weg daran vorbei.

Warum nicht einfach Namespaces?

Eine berechtigte Frage. Kubernetes Namespaces mit strikten NetworkPolicies und RBAC koennen durchaus verschiedene Sicherheitszonen abbilden. Aber sie teilen sich den API-Server, etcd und in der Regel die Node-Hardware.

Ein kompromittierter API-Server bedeutet Zugriff auf alle Namespaces. Ein Container-Escape auf einem Shared Node gibt Zugang zu allen Pods auf diesem Node. Fuer die meisten Anwendungsfaelle ist das akzeptabel. Fuer Red/Black nicht.

Die Entscheidung ist letztlich eine Risikoabwaegung. Fuer die meisten Produktionsumgebungen reichen Namespaces mit strikten Policies. Fuer echte Red/Black-Anforderungen nicht.

Architektur im Detail

Red Cluster

Der Red Cluster verarbeitet alle klassifizierten Workloads. Er hat keinen Internetzugang. Container-Images werden ueber ein Air-Gap-Verfahren eingespielt -- typischerweise ueber ein gehärtetes Transfer-Medium, das vorher gescannt wurde.

Wichtig: Auch innerhalb des Red Clusters sollten NetworkPolicies den Traffic zwischen Pods einschraenken. Default Deny ist Pflicht.

Black Cluster

Der Black Cluster beherbergt Management-Tools, Monitoring, Log-Aggregation und die Anbindung an externe Netze. Er ist der "normale" Cluster, der nach gaengigen Best Practices betrieben wird.

Data Diode

Die Data Diode ist ein Hardware-Geraet, das physikalisch nur einen unidirektionalen Datenstrom zulässt. Typischerweise von Red nach Black, um aggregierte Metriken oder anonymisierte Daten zu exportieren. Der umgekehrte Weg ist physikalisch unmoeglich -- kein ACK, kein Handshake, kein Rueckkanal.

Das bedeutet: Protokolle wie TCP funktionieren nicht nativ ueber eine Data Diode, weil TCP einen Rueckkanal braucht. Stattdessen werden UDP-basierte Proxy-Loesungen eingesetzt, die auf der Sender-Seite (Red) Pakete in einen UDP-Stream konvertieren und auf der Empfaenger-Seite (Black) wieder zusammensetzen.

NetworkPolicy fuer den Red Cluster

Innerhalb des Red Clusters gilt Default Deny auf allen Ebenen. Jeder erlaubte Kommunikationspfad wird explizit freigeschaltet.

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

Anschliessend werden gezielt die benoetigten Verbindungen erlaubt:

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

Die DNS-Ausnahme fuer kube-system ist wichtig -- ohne sie kann der Pod keine Service-Namen aufloesen. Vergisst man das, stehen Pods ohne Netzwerk da, und das Debugging dauert laenger als noetig.

Cluster-Haertung per Bash

Neben NetworkPolicies gehoert die Haertung auf Node-Ebene dazu. CIS Benchmarks lassen sich mit kube-bench automatisiert pruefen:

# kube-bench auf einem Node ausfuehren (als Container)
docker run --rm --pid=host \
  -v /etc:/etc:ro \
  -v /var:/var:ro \
  aquasec/kube-bench:latest run --targets node

# Ergebnisse filtern: nur FAIL und WARN
docker run --rm --pid=host \
  -v /etc:/etc:ro \
  -v /var:/var:ro \
  aquasec/kube-bench:latest run --targets node \
  | grep -E '^\[FAIL\]|^\[WARN\]'

# API-Server-Audit-Logging aktivieren (kube-apiserver Flag)
# In der Static Pod Manifest Datei (/etc/kubernetes/manifests/kube-apiserver.yaml):
# --audit-policy-file=/etc/kubernetes/audit-policy.yaml
# --audit-log-path=/var/log/kubernetes/audit.log
# --audit-log-maxage=30
# --audit-log-maxbackup=10

Fuer den Red Cluster empfiehlt es sich, kube-bench mit dem Profil "cis-1.8" oder hoeher auszufuehren und alle FAIL-Ergebnisse zu beheben, bevor Workloads deployt werden.

Terraform-Beispiel: Zwei getrennte Cluster

Wer die Infrastruktur als Code verwaltet, kann die Trennung bereits auf Terraform-Ebene erzwingen. Hier ein vereinfachtes Beispiel fuer zwei vSphere-basierte Cluster (On-Premise, kein Cloud-Provider):

module "red_cluster" {
  source = "./modules/k8s-cluster"

  cluster_name    = "red-cluster"
  network_id      = vsphere_network.red_network.id
  node_count      = 3
  node_cpu        = 4
  node_memory_mb  = 16384
  disk_size_gb    = 100
  dns_servers     = ["10.10.1.2"]  # Red-interner DNS
  ntp_servers     = ["10.10.1.3"]  # Red-interner NTP
  internet_access = false

  tags = {
    security_zone = "red"
    classification = "vs-nfd"
  }
}

module "black_cluster" {
  source = "./modules/k8s-cluster"

  cluster_name    = "black-cluster"
  network_id      = vsphere_network.black_network.id
  node_count      = 3
  node_cpu        = 4
  node_memory_mb  = 16384
  disk_size_gb    = 200
  dns_servers     = ["10.20.1.2"]  # Black-DNS mit Upstream
  ntp_servers     = ["10.20.1.3"]
  internet_access = true

  tags = {
    security_zone = "black"
    classification = "unclassified"
  }
}

# Keine Netzwerkverbindung zwischen red_network und black_network
# Data Diode wird physisch konfiguriert, nicht per Terraform

Entscheidend: Die beiden Netzwerke (red_network, black_network) duerfen keinerlei Routing zueinander haben. Das wird auf Switch-/Firewall-Ebene erzwungen, nicht in Terraform.

Vergleich: Red/Black vs. Air-Gap vs. Standard-Segmentierung

Red/Black mit Data Diode ist der Kompromiss zwischen vollstaendigem Air-Gap (kein automatisierter Datenfluss moeglich) und normaler Segmentierung (bidirektional, Software-basiert). Fuer die meisten Hochsicherheitsszenarien ist er der pragmatischste Ansatz.

Audit-Logging: Wer hat was getan?

In einer Red/Black Architektur ist lueckenlose Nachvollziehbarkeit Pflicht. Jeder API-Aufruf im Red Cluster muss protokolliert werden. Kubernetes bietet dafuer Audit Logging auf API-Server-Ebene.

Eine sinnvolle Audit Policy fuer den Red Cluster loggt alle write-Operationen vollstaendig und read-Operationen auf Metadata-Ebene:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: ""
        resources: ["pods", "secrets", "configmaps", "services"]
      - group: "apps"
        resources: ["deployments", "statefulsets", "daemonsets"]
  - level: Metadata
    verbs: ["get", "list", "watch"]
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: ""
        resources: ["endpoints", "services"]

Die Audit Logs des Red Clusters bleiben lokal. Sie duerfen nicht ueber die Data Diode exportiert werden, weil sie klassifizierte Informationen enthalten koennen (z.B. Secret-Namen, Pod-Konfigurationen). Fuer den Black Cluster koennen Audit Logs normal in ein SIEM-System exportiert werden.

Mehr zum Thema Audit Logging unter Kubernetes Audit Logging.

Stolpersteine in der Praxis

Container-Image-Distribution: Der Red Cluster hat keinen Registry-Zugang. Images muessen ueber ein sicheres Transfer-Verfahren eingespielt werden. Das bedeutet: lokale Registry im Red-Netz, Befuellung ueber gescannte Medien. CI/CD im klassischen Sinne funktioniert hier nicht.

Zeitserversynchronisation: Ohne NTP-Zugang zum Internet braucht der Red Cluster eine eigene Zeitquelle. Abweichende Uhrzeiten fuehren zu TLS-Fehlern und machen Log-Korrelation unmoeglich.

Zertifikatsmanagement: Separate CAs fuer Red und Black. Keine gemeinsamen Root-Zertifikate. Cert-Manager im Red Cluster muss gegen eine interne CA arbeiten.

Monitoring: Prometheus im Red Cluster sammelt Metriken lokal. Aggregierte, anonymisierte Metriken werden ueber die Data Diode an ein Grafana im Black Cluster gesendet. Alerting muss in beiden Clustern unabhaengig funktionieren.

Wann braucht man das wirklich?

Nicht jedes Unternehmen braucht eine Red/Black Architektur. Die Implementierung ist teuer, der Betrieb aufwaendig, und die Einschraenkungen sind real. Sinnvoll ist der Ansatz, wenn:

• Workloads Geheimhaltungsstufen ab VS-NfD verarbeiten
• Regulatorische Anforderungen (BSI IT-Grundschutz, KRITIS) eine physische Trennung verlangen
• Das Bedrohungsmodell staatliche Akteure einschliesst
• Bidirektionale Kommunikation zwischen Zonen ein inakzeptables Risiko darstellt

Fuer alle anderen Faelle ist eine solide Netzwerk-Segmentierung mit NetworkPolicies in Kombination mit RBAC und Runtime Security der bessere Ansatz -- deutlich einfacher zu betreiben und trotzdem wirksam.

Weitergehende Themen

• Kubernetes Penetration Testing -- Wie Sie Ihre Cluster-Sicherheit validieren
• Secrets Management mit Vault -- Kryptographische Schluessel sicher verwalten
• Kubernetes Compliance und DSGVO -- Regulatorische Anforderungen systematisch umsetzen

Fazit

Die Red/Black Architektur ist kein Alltagswerkzeug. Sie ist das Mittel der Wahl, wenn die Konsequenzen eines Sicherheitsvorfalls ueber finanzielle Schaeden hinausgehen. Zwei getrennte Cluster, eine Data Diode dazwischen, Default Deny ueberall -- das ist das Grundrezept.

Der Betriebsaufwand ist hoch, aber beherrschbar, wenn man von Anfang an auf Automatisierung setzt. Infrastructure as Code, automatisierte CIS-Benchmark-Pruefungen und ein klares Datenflussmodell sind die Grundlagen.

Wenn Sie vor der Entscheidung stehen, ob eine Red/Black Architektur fuer Ihre Anforderungen das Richtige ist, oder ob eine weniger aufwaendige Segmentierung ausreicht -- sprechen Sie mit jemandem, der beide Varianten implementiert hat. Wir helfen gerne bei der Bewertung. Kontaktieren Sie uns unter /kontakt.