Kubernetes über Sicherheitsenklaven hinweg: mehrstufige Cluster

Verteidigungsprogramme arbeiten selten auf einer einzigen Geheimhaltungsstufe. Dieselbe Missionssoftware, die in einer Unclassified-Enklave Open-Source-Feeds aufnimmt, hat oft eine Secret-Variante, die sie mit sensibler Aufklärung fusioniert, und manchmal obendrein eine Top-Secret-Variante. Der Instinkt eines Ingenieurs, der an kommerzielles Kubernetes gewöhnt ist, ist es, diese Stufen als Namespaces, Mandanten oder virtuelle Cluster innerhalb einer Plattform zu modellieren. Dieser Instinkt ist für die Verschlussarbeit falsch, und ihn falsch zu treffen ist teuer rückgängig zu machen. In einer mehrstufig sicheren (MLS) Umgebung ist der Kubernetes-Cluster — und das Netzwerk, in dem er sitzt — die Geheimhaltungsgrenze, kein Mandanten-Detail darin. Dieser Artikel führt durch, wie man Kubernetes über Sicherheitsenklaven hinweg betreibt: ein akkreditierter Cluster pro Geheimhaltungsstufe, strikte Richtlinienisolation innerhalb jedes einzelnen, überprüfbare Image-Herkunft und kontrollierte, einseitige Heraufstufung von Artefakten zwischen Domänen.

Die Grenze ist der Cluster, nicht der Namespace

Kubernetes bietet mehrere Mechanismen, die wie Isolation aussehen: Namespaces, NetworkPolicies, RBAC, Ressourcenkontingente und Admission-Kontrolle. Jeder von ihnen ist eine Mandantenkontrolle, die innerhalb einer einzigen Vertrauensgrenze arbeitet. Sie alle teilen sich denselben API-Server, denselben etcd-Datenspeicher, denselben Linux-Kernel auf jedem Knoten und dieselbe Container-Laufzeit. Ein Container-Ausbruch über eine Kernel-Schwachstelle, ein Fehler im Autorisierungspfad des API-Servers oder ein einziges zu weites ClusterRoleBinding kann all diese weichen Grenzen auf einmal überschreiten.

Ein Akkreditierer, der ein MLS-System betrachtet, stellt eine einfache Frage: Was hindert Secret-Daten physisch oder kryptografisch daran, die Unclassified-Seite zu erreichen? „Eine NetworkPolicy" ist keine akzeptable Antwort, denn eine NetworkPolicy wird vom selben CNI-Plugin und Kernel durchgesetzt, auf dem die Workloads selbst laufen. Die akzeptierte Antwort ist Trennung: separate Cluster, separate Netzwerke, separate Hardware oder separate kryptografisch isolierte Partitionen, jede akkreditiert für die Verarbeitung genau einer Stufe. Namespaces bleiben nützlich — aber nur als administrative Kompartimente innerhalb einer einzigen Enklave, niemals als die Linie zwischen Unclassified und Secret.

Das ist dasselbe Prinzip, das Cross-Domain-Solutions für die Verteidigung zugrunde liegt: Daten bewegen sich nur über einen akkreditierten Guard zwischen Stufen, niemals über eine gemeinsame Software-Kontrolle, die beide Seiten erreichen können. Multi-Enklaven-Kubernetes wendet dieses Prinzip einfach auf die Orchestrierungsebene an.

Ein Cluster pro Enklave: die Referenztopologie

Die Referenztopologie für ein dreistufiges Programm besteht aus drei vollständig unabhängigen Kubernetes-Bereitstellungen, eine pro Enklave:

Unclassified- / Entwicklungs-Enklave. Hier findet die meiste Ingenieursarbeit statt. Sie hat die breiteste Konnektivität (oft einen Pfad ins Internet über einen Proxy zum Ziehen von Upstream-Abhängigkeiten), die freizügigste Änderungskadenz und die Build-Pipeline, die die Artefakte produziert, die die höheren Enklaven schließlich konsumieren werden. Sie ist dennoch gehärtet — Default-Deny-Netzwerk, signierte Images, keine privilegierten Pods — aber sie ist die einzige Enklave, in der neue Images entstehen.

Secret-Enklave. Vom öffentlichen Internet getrennt, betreibt dieser Cluster die Secret-Variante der Missionssoftware. Er zieht Images nur aus seiner eigenen Registry innerhalb der Enklave, die ausschließlich durch Heraufstufung von unten befüllt wird. Seine Änderungskadenz ist langsamer, und jede Bereitstellung ist an ein akkreditiertes Release gebunden. Die operative Disziplin hier ähnelt einer air-gapped Kubernetes-Bereitstellung — Offline-Registries, keine Live-Upstream-Pulls und ein Upgrade-Prozess, der die Akkreditierung überstehen muss.

Top-Secret-Enklave. Der am stärksten eingeschränkte Cluster, im am stärksten isolierten Netzwerk, mit den strengsten Personal- und physischen Kontrollen. Er erhält eine kuratierte Teilmenge von Artefakten von der Secret-Seite, wiederum nur über eine akkreditierte Übertragung.

Jede Enklave ist ein vollständiges, autarkes Kubernetes-Universum: eigene Steuerungsebene und etcd, eigenes CNI und eigene Storage-Klassen, eigene Image-Registry, eigener Identitätsanbieter und RBAC, eigener GitOps-Controller und eigener Observability-Stack. Nichts in einer höheren Enklave hängt davon ab, dass ein Dienst in einer niedrigeren Enklave zur Laufzeit erreichbar ist. Diese Unabhängigkeit ist es, die es erlaubt, jeden Cluster zu seinen eigenen Bedingungen zu akkreditieren.

Warum Föderation über Stufen hinweg ein verdeckter Kanal ist

Die verlockende Abkürzung ist, Identität, Image-Verteilung oder GitOps über die Enklaven hinweg zu föderieren, damit Operatoren eine Konsole haben. Widerstehen Sie. Eine lebende Authentifizierungsföderation, die ein Token ausgibt, das sowohl auf der Unclassified- als auch auf der Secret-Seite nutzbar ist, ist per Definition ein Echtzeitkanal zwischen den beiden Stufen — genau das, was die Trennung verhindern soll. Das Vorhandensein oder Fehlen einer erfolgreichen Anmeldung, das Timing von Token-Aktualisierungen, sogar Fehlercodes können Informationen über die Grenze kodieren. Dieselbe Logik schließt eine gemeinsame Registry aus, in die beide Seiten schreiben, oder einen einzelnen GitOps-Controller, der Cluster auf verschiedenen Stufen abgleicht. Alles, was eine synchrone Verbindung über die Grenze aufrechterhält, ist ein potenzieller verdeckter Kanal und wird die Prüfung nicht bestehen.

Richtlinienisolation innerhalb jeder Enklave

Trennung zwischen Enklaven ist notwendig, aber nicht hinreichend. Innerhalb jedes Clusters brauchen Sie immer noch rigorose Kompartimentierung, denn eine Enklave beherbergt viele Workloads, Dienste und Teams, die nicht frei aufeinander zugreifen sollten. Hier verdienen sich die Kubernetes-nativen Kontrollen ihren Platz.

Beginnen Sie mit der Admission-Kontrolle. Eine Richtlinien-Engine wie Kyverno oder OPA Gatekeeper erzwingt nicht verhandelbare Regeln im Moment, in dem ein Workload zugelassen wird: nur signierte Images aus der eigenen Registry der Enklave dürfen laufen; kein Pod darf privilegierten Modus, Host-Networking oder Host-Path-Mounts anfordern; jeder Container läuft als Non-Root-Benutzer mit schreibgeschütztem Root-Dateisystem und reduziertem Capability-Set; und jeder Namespace erfüllt das restricted-Profil der Pod Security Standards. Das sind dieselben Härtungskontrollen, die ausführlich in Kubernetes-Härtung für Verteidigungs-Workloads behandelt werden, identisch in jeder Enklave angewendet, sodass die Baseline nicht zwischen den Stufen abdriftet.

Das Netzwerk innerhalb der Enklave ist Default-Deny. Jeder Namespace beginnt mit einer NetworkPolicy, die allen Ingress und Egress verwirft, und Konnektivität wird explizit pro Dienstpaar gewährt. Ost-West-Verkehr zwischen sensiblen Kompartimenten läuft über mutual TLS, typischerweise durch ein Service Mesh, sodass die Identität eines Workloads — nicht nur seine Netzwerkposition — den Zugriff steuert. Ressourcenkontingente und Limit-Ranges verhindern, dass ein einzelner kompromittierter oder fehlerhafter Workload den Cluster aushungert.

RBAC und die Break-Glass-Disziplin

RBAC innerhalb jeder Enklave folgt ausnahmslos dem Prinzip der geringsten Privilegien. Tägliche Operatoren erhalten namespace-beschränkte Rollen; niemand hält stehendes cluster-admin. Die cluster-admin-Fähigkeit lebt hinter einem Break-Glass-Verfahren: ein Anmeldedaten, das versiegelt ist, dessen Nutzung einen Alarm auslöst und dessen jede Aktion in unveränderlichem Audit-Speicher festgehalten wird. Da die Enklaven unabhängig sind, ist auch das Break-Glass-Verfahren unabhängig — seine Nutzung in der Secret-Enklave gewährt nichts in der Unclassified-Enklave. Dienstkonten sind auf einen einzigen Namespace beschränkt, ihre Tokens sind kurzlebig und an einen bestimmten Workload gebunden, und keines von ihnen wird jemals über Cluster hinweg wiederverwendet.

Image-Herkunft: beim Build verdientes, zur Laufzeit verifiziertes Vertrauen

In einer Multi-Enklaven-Architektur ist die Lieferkette die attraktivste Angriffsfläche, denn ein einmal auf der niedrigen Seite gebautes Image kann schließlich bei Top Secret laufen. Jedes Image muss daher eine überprüfbare Herkunft tragen, die die höchste Enklave prüfen kann, ohne zur Laufzeit irgendeiner niedrigeren Enklave zu vertrauen.

Die Disziplin lautet: bauen Sie in der niedrigsten Enklave, die das Image bauen kann, erzeugen Sie eine vollständige Software-Stückliste (SBOM) im SPDX- oder CycloneDX-Format, scannen Sie sie gegen eine in diese Enklave gespiegelte Schwachstellendatenbank und signieren Sie sowohl das Image als auch die SBOM mit einem Sigstore-Cosign-Schlüssel. Die Signatur bindet den Image-Digest an einen bekannten Build-Prozess. Jede Enklave betreibt ihre eigene Registry — Harbor und zot sind die gängigen Wahlmöglichkeiten für getrennten Betrieb — und der Admission-Controller jedes Clusters verifiziert die Cosign-Signatur gegen einen enklavenspezifischen öffentlichen Schlüssel, bevor das Image laufen darf. Ein unsigniertes Image oder eines, dessen Digest nicht mit dem heraufgestuften Eintrag übereinstimmt, startet nie.

Das ist über die Grenze hinweg wichtig, weil der High-Side-Cluster der Low-Side-Registry nicht vertraut; er vertraut der kryptografischen Signatur und dem während der Heraufstufung erfassten Digest. Selbst wenn die Low-Side-Registry nach der Heraufstufung eines Images kompromittiert würde, würde die hohe Seite jeden Ersatz ablehnen, dessen Digest sich von dem erfassten unterscheidet.

Kontrollierte Heraufstufung zwischen Domänen

Die Heraufstufung ist der einzige sanktionierte Weg, auf dem ein Artefakt eine Enklavengrenze überschreitet, und sie ist strikt low-to-high. Der Pfad läuft über eine akkreditierte Cross-Domain-Solution oder, für die strengsten Verbindungen, eine Hardware-Datendiode, die den Transfer physisch nur in einer Richtung erlaubt.

Der Transfer-Guard leistet echte Arbeit, nicht nur eine Kopie. Er validiert den Image-Digest und die Cosign-Signatur gegen eine Allowlist genehmigter Artefakte; er inspiziert die SBOM und lehnt jedes Image ab, das eine verbotene Komponente, eine nicht genehmigte Lizenz oder ein bekannt verwundbares Paket über der Schwelle des Programms enthält; er entfernt oder normalisiert Metadaten, die versteckte Daten tragen könnten; und er protokolliert die Übertragung mit Operator-Identität, Zeitstempel und Artefakt-Digest in einem Audit-Datensatz auf beiden Seiten. Erst nachdem jede Prüfung bestanden ist, wird das Artefakt in die High-Side-Registry geschrieben, wo der hohe Cluster es ziehen kann.

Die Bewegung von hoch nach niedrig ist die gefährliche Richtung und wird entsprechend behandelt. Logs, Metriken oder Build-Telemetrie aus einer Secret-Enklave in eine Unclassified herunterzuziehen, ist ein potenzielles Spill, also ist es entweder schlicht verboten oder wird über eine gesonderte, weitaus strengere Prüfung mit menschlicher Beurteilung jedes freigegebenen Datensatzes geleitet. Die Standardhaltung ist, dass Daten nach oben fließen und oben bleiben.

GitOps und Betrieb, ohne die Linie zu überschreiten

Jede Enklave betreibt ihren eigenen GitOps-Controller — Argo CD oder Flux — der gegen ein Git-Repository abgleicht, das innerhalb dieser Enklave lebt. Die Desired-State-Manifeste für die höhere Enklave sind selbst Artefakte, die über die Cross-Domain-Solution heraufgestuft werden, genauso geprüft wie Images. Das bewahrt den Audit-Trail (das High-Side-Repository erfasst genau, was heraufgestuft wurde und von wem), ohne jemals einen Controller über die Grenze zu verbinden.

Observability folgt derselben Regel. Falco zur Laufzeit-Bedrohungserkennung, das Kubernetes-Audit-Log, Prometheus-Metriken und zentralisierte Container-Logs laufen alle innerhalb jeder Enklave und speisen ein enklavenlokales SIEM. Telemetrie wird nie aus einer hohen Enklave auf ein Low-Side-Dashboard gestreamt; falls ein fusioniertes, stufenübergreifendes operatives Lagebild wirklich erforderlich ist, wird es erstellt, indem geprüfte Zusammenfassungen nach oben in die höchste Enklave exportiert werden, nicht indem rohe Telemetrie nach unten gezogen wird. Die Audit-Aufbewahrung wird pro Enklave festgelegt, um die Akkreditierungsanforderung dieser Enklave zu erfüllen, und kontinuierliche Überwachung — erneute Schwachstellen-Scans gegen den Spiegel in der Enklave, Drift-Erkennung, periodische erneute Verifikation von Image-Signaturen — läuft unabhängig in jedem Cluster.

Was das kostet, und warum es sich lohnt

Drei unabhängige Cluster statt eines mandantenfähigen Clusters zu betreiben, ist tatsächlich mehr Arbeit: drei Steuerungsebenen zu patchen, drei Registries zu befüllen, drei Identitätsanbieter, drei GitOps-Pipelines und ein Heraufstufungsprozess zwischen ihnen. Ingenieure spüren die Reibung jedes Mal, wenn ein Image, das auf der niedrigen Seite funktioniert, heraufgestuft werden muss, bevor es höher laufen kann. Aber diese Reibung ist die Sicherheitseigenschaft, kein Defekt davon. Das Heraufstufungs-Gate ist der Ort, an dem die Herkunft verifiziert wird, verbotene Komponenten abgefangen werden und ein vollständiger, unveränderlicher Datensatz dessen erstellt wird, was die Grenze überschritten hat. Die Enklaven in einen Cluster zusammenzufassen, um Aufwand zu sparen, würde eine akkreditierbare, verteidigbare Architektur gegen einen einzigen gemeinsamen Kernel und API-Server eintauschen, der zwischen Unclassified und Secret steht — ein Tausch, den kein Akkreditierer akzeptieren wird und den kein Programm wollen sollte.

Für Teams, die auch die höheren Enklaven getrennt halten müssen, passen die operativen Muster natürlich zu einer air-gapped Kubernetes-Praxis: Offline-Registries, gespiegelte Abhängigkeiten und eine Upgrade-Disziplin, die keinen lebenden Pfad zur Außenwelt annimmt.