Service Mesh für militärisches Zero-Trust: mTLS, Durchsetzung von Richtlinien und Observability in Verteidigungsclustern

Ein Kubernetes-Cluster, auf dem Verteidigungsmicroservices laufen, ist nicht von Natur aus Zero-Trust. Das Standard-Pod-Netzwerkmodell erlaubt es jedem Pod, eine TCP-Verbindung zu jedem anderen Pod im selben Cluster-Netzwerk herzustellen. Das bedeutet, dass ein einziger kompromittierter Container Authentifizierungsdienste, Datenspeicher und Befehlsschnittstellen erreichen kann, zu denen er keinen legitimen Grund für einen Zugriff hat. Ein Service Mesh löst dieses Problem nicht durch die Neukonfiguration von Netzwerk-ACLs – die in dynamischen Container-Umgebungen unzuverlässig sind –, sondern indem es kryptografische Identität und Richtliniendurchsetzung direkt in den Datenpfad jedes Service-zu-Service-Aufrufs einfügt. Dieser Artikel untersucht, was das in der Praxis für Verteidigungscluster bedeutet: wie SPIFFE/SPIRE mit der Zero-Trust-Architektur für militärische Netzwerke integriert wird, wie absichtsbasierte Richtlinien das Perimeter-Denken innerhalb des Clusters ersetzen und wie vollständige Observability aufrechterhalten werden kann, ohne dass Telemetrie die Klassifizierungsgrenze überschreitet.

Warum Perimetersicherheit in Verteidigungsmicroservice-Clustern versagt

Das Perimetersicherheitsmodell geht davon aus, dass der Datenverkehr innerhalb einer vertrauenswürdigen Netzwerkgrenze sicher ist. In einer monolithischen Anwendung hat diese Annahme eine gewisse Gültigkeit: Es gibt einen Prozess, eine Vertrauensgrenze und verhältnismäßig wenige interne Kommunikationspfade, die abgesichert werden müssen. In einer auf Kubernetes bereitgestellten Microservice-Architektur bricht diese Annahme vollständig zusammen. Ein Cluster mit 20 Diensten hat in der Größenordnung von 400 möglichen Dienstpaaren. Nicht alle sollten miteinander kommunizieren, aber ohne explizite Durchsetzung auf Dienstebene können es alle. Eine Schwachstelle in einem einzigen Dienst – eine Abhängigkeit mit einer Remote-Code-Execution-Lücke, eine falsch konfigurierte Umgebungsvariable, die Zugangsdaten preisgibt, ein nicht gepatchtes Basis-Image – gibt einem Angreifer Lateralbewegungsfähigkeiten im gesamten Cluster-Netzwerk.

Das Fehlermuster ist nicht theoretisch. Supply-Chain-Kompromittierungen, die auf Container-Workloads abzielen, haben gezeigt, dass ein Angreifer nach der Code-Ausführung innerhalb eines Pods das Cluster-Netzwerk aggressiv abtastet. Ohne gegenseitige Authentifizierung gibt es nichts, das den kompromittierten Pod daran hindert, interne APIs direkt aufzurufen: Er hat bereits eine gültige Cluster-IP, seine Anfragen kommen aus einem vertrauenswürdigen CIDR-Bereich, und der Zieldienst hat keine Möglichkeit, die Identität des Anrufers zu verifizieren. Traditionelle Netzwerksegmentierung über Kubernetes-NetworkPolicy hilft auf der IP-/Port-Schicht, verhindert jedoch weder die Identitätsübernahme eines legitimen Pods innerhalb des zulässigen Adressbereichs, noch erzwingt sie anwendungsschichtseitige Einschränkungen hinsichtlich der erlaubten Operationen.

Ein Service Mesh löst dies, indem es kryptografische Workload-Identität für jede Verbindung zur Pflicht macht. Jeder Sidecar-Proxy präsentiert ein SPIFFE Verifiable Identity Document (SVID) – ein kurzlebiges X.509-Zertifikat, das die Dienstkonto-Identität des Pods kodiert – und verlangt, dass der entfernte Sidecar ein gültiges SVID präsentiert, bevor Anwendungsdaten fließen. Die Identitätsprüfung erfolgt auf der Transportschicht, transparent für die Anwendung, und kann von einem Angreifer, der nur den Anwendungsprozess im Container kontrolliert, nicht umgangen werden. Die Lateralbewegung wird von „jeden Pod im Cluster-Netzwerk erreichen" auf „nur Pods erreichen, deren Richtlinie Ihren SVID explizit als Quelle erlaubt" reduziert.

Wahl eines Service Mesh: Istio vs. Linkerd vs. Cilium in air-gapped Umgebungen

Drei Service-Mesh-Implementierungen sind für Verteidigungsumgebungen mit Kubernetes produktionsreif, jede mit einem anderen Kompromissprofi. Istio ist das funktionsreichste: seine Envoy-basierte Datenebene unterstützt umfangreiches L7-Verkehrsmanagement einschließlich Fehlerinjektion, Wiederholungsversuche, Circuit Breaking, Request Mirroring und granularer AuthorizationPolicy. Die Steuerungsebene – istiod – integriert sich nativ mit SPIFFE/SPIRE für externe Zertifikatsausstellung, und ihre Telemetrie-Pipeline gibt OpenTelemetry-kompatible Metriken und Traces von jedem Sidecar aus. Die Kosten sind operative Komplexität: Istio hat eine steilere Lernkurve, einen größeren Steuerungsebenen-Footprint und Envoy-Sidecars, die mehr Speicher pro Pod verbrauchen als Alternativen. Für Cluster mit 16+ GB RAM pro Knoten und Teams mit Erfahrung in der Envoy-Konfiguration ist die Richtlinienausdrucksfähigkeit von Istio schwer zu übertreffen.

Linkerd verfolgt den entgegengesetzten Ansatz. Sein Datenebenen-Proxy ist in Rust geschrieben und auf Ultraleichtbau ausgelegt: jeder linkerd-proxy-Sidecar verwendet 10–20 MB Resident Memory und fügt unter 1 ms Latenz pro Hop hinzu, verglichen mit 50–100 MB und 0,5–3 ms für Envoy. Linkerd's Zero-Konfiguration mTLS ist standardmäßig für den gesamten Mesh-Datenverkehr aktiviert, ohne dass ein PeerAuthentication-Manifest erforderlich ist, was das Risiko einer falsch konfigurierten Klartext-Ausnahme reduziert. Der Kompromiss besteht darin, dass Linkerd's Richtlinienmodell auf HTTP-Methoden- und Pfadebene weniger ausdrucksstark ist und sein Steuerungsebene sich weniger direkt mit externen SPIRE-Ausstellern integriert als Istio. Für ressourcenbeschränkte Edge-Cluster mit begrenztem Pro-Knoten-RAM ist Linkerd's Proxy-Effizienz ein erheblicher operativer Vorteil.

Cilium operiert auf der eBPF-Schicht statt als Sidecar. Indem die Richtliniendurchsetzung in die eBPF-Programme des Linux-Kernels eingebettet wird, die an der Netzwerkschnittstelle jedes Pods angehängt sind, erreicht Cilium nahezu null Pro-Workload-Overhead für Netzwerkrichtliniendurchsetzung und grundlegendes mTLS. Seine CiliumNetworkPolicy-Ressource unterstützt SPIFFE-identitätsbewusste Regeln durch Integration mit der SPIRE-API, und die Hubble-Observability-Komponente bietet L4/L7-Flow-Sichtbarkeit im Cluster. Ciliums Stärke ist Performance und sein nahtloser Ersatz für kube-proxy; seine Einschränkung besteht darin, dass die L7-HTTP/gRPC-Richtliniendurchsetzung via eBPF für komplexe Autorisierungsszenarien weniger ausgereift ist als Isios Envoy-basiertes Äquivalent. In der Praxis betreiben viele Verteidigungscluster Cilium als CNI für Netzwerkrichtlinien und Verschlüsselung, mit Istio oder Linkerd als Schicht darüber für L7-Observability und granulare Service-Level-AuthorizationPolicy.

Gegenseitiges TLS: Zertifikatsausstellung, Rotation und SPIFFE/SPIRE-Integration

Gegenseitiges TLS in einem Service Mesh bedeutet, dass sich beide Seiten jeder Verbindung gegenseitig mit X.509-Zertifikaten authentifizieren, bevor Anwendungsdaten ausgetauscht werden. Die entscheidende Frage für eine Verteidungsbereitstellung ist, wie diese Zertifikate ausgestellt werden, wie häufig sie rotieren und wer die Vertrauensgrundlage kontrolliert. Natives Istio verwendet seine eigene integrierte Zertifizierungsstelle (die istiod-CA), die standardmäßig 24 Stunden gültige Workload-Zertifikate ausstellt. Für eine Verteidigungsbereitstellung ist dies aus zwei Gründen unzureichend: der Root-Schlüssel befindet sich im Cluster (ein kompromittierter istiod-Prozess gibt alle Workload-Identitäten preis), und 24-Stunden-TTLs sind zu lang für Umgebungen, in denen eine schnelle Widerrufung von Zugangsdaten erforderlich sein kann.

SPIRE bietet die richtige Architektur für Verteidigungskontexte. Der SPIRE-Server läuft als StatefulSet mit seinem Trust Bundle und seinen Registrierungseinträgen, die in einem Datenspeicher außerhalb des Clusters aufbewahrt werden können. Der SPIRE-Agent läuft als DaemonSet auf jedem Knoten und übernimmt die Workload-Attestierung, indem er das Kubernetes-Dienstkonto-Token jedes Pods gegen den API-Server verifiziert, bevor ein SVID ausgestellt wird. Ausgestellte SVIDs haben konfigurierbare TTLs – Produktionsverteidigungsbereitstellungen verwenden 1-Stunden-TTLs für Standard-Workloads und 15-Minuten-TTLs für Workloads, die klassifizierte Daten verarbeiten – und der SPIRE-Agent übernimmt die Rotation automatisch, indem er einen neuen SVID an den Workload-Socket sendet, bevor der aktuelle abläuft. Der Mesh-Sidecar liest den SVID über den SPIFFE-Workload-API-Socket und präsentiert ihn bei allen ausgehenden TLS-Verbindungen, ohne Änderungen am Anwendungscode zu erfordern.

Die Integration von SPIRE mit Istio erfordert die Konfiguration von istiod, SPIRE als Zertifikatsanbieter über die Upstream-CA-Plugin-Schnittstelle zu verwenden. Isios CustomCA-Konfiguration verweist istiod auf den SPIRE-Server-GRPC-Port und delegiert die gesamte SVID-Ausstellung und -Rotation an SPIRE, während Istio die PeerAuthentication- und AuthorizationPolicy-Durchsetzung übernimmt. Diese Trennung der Zuständigkeiten ist wichtig: SPIRE besitzt den Identitätslebenszyklus (Attestierung, Ausstellung, Rotation), während Istio den Richtlinienlebenszyklus (welche Identitäten auf welchen Pfaden kommunizieren dürfen) besitzt. Ein Operator, der den Zugang eines Workloads widerruft, entfernt seinen SPIRE-Registrierungseintrag, was dazu führt, dass die nächste SVID-Rotation fehlschlägt und der Workload bei der nächsten Zertifikatserneuerung aus dem Mesh herausgeschnitten wird, ohne dass Richtlinienmanifest-Änderungen erforderlich sind.

Absichtsbasierte Verkehrsrichtlinien: Allowlisting von Ost-West-Kommunikation

Das Default-Deny-Prinzip erfordert, dass kein Dienst-zu-Dienst-Datenverkehr erlaubt ist, es sei denn, er wird durch eine Richtlinie explizit erlaubt. In Istio wird dies mit einem Cluster-weiten AuthorizationPolicy-Manifest implementiert, das einen leeren Regelblock und action: DENY hat – was den gesamten Datenverkehr blockiert – gefolgt von engen Erlaubnisrichtlinien für jedes legitime Dienstpaar. Jede Erlaubnisrichtlinie benennt den Quellprinzipal (den SPIFFE-URI des Dienstkontos des aufrufenden Dienstes), den Zieldienst und die präzise Menge der HTTP-Methoden oder gRPC-Dienstnamen, für die der Aufruf autorisiert ist. Eine Richtlinie, die einem Sensordaten-Aufnahmedienst erlaubt, per POST an die Datenfusions-API zu senden, erlaubt ihm beispielsweise nicht, historische Datensätze per GET abzurufen oder den Verwaltungsendpunkt aufzurufen, auch wenn beide auf demselben Zieldienstport laufen. Die Granularität liegt auf Operationsebene, nicht nur auf TCP-Verbindungsebene.

Das Schreiben und Pflegen dieses Richtliniensatzes erfordert Disziplin. Ein Cluster, der über 18 Monate von 10 auf 30 Dienste wächst, sammelt Hunderte von Erlaubniseinträgen an, und veraltete Einträge für außer Betrieb genommene Dienste werden zu latenter Angriffsfläche. Zwei Praktiken verhindern diese Anhäufung. Erstens: Behandeln Sie AuthorizationPolicy-Manifeste als Code – speichern Sie sie im selben versionskontrollierten Repository wie die Anwendungsmanifeste, verlangen Sie eine Peer-Review für jeden neuen Erlaubniseintrag und überprüfen Sie den Richtliniensatz vierteljährlich anhand der Liste der aktuell laufenden Dienste. Zweitens: Nutzen Sie das Zugriffs-Logging des Mesh – jede abgelehnte Anfrage erzeugt einen Zugriffs-Log-Eintrag im Sidecar, der den verifizierten Quell-SVID, das Ziel und die Operation enthält – um legitime Verkehrspfade zu identifizieren, denen eine Richtlinie fehlt, anstatt das Mesh stillschweigend zu umgehen. Dieses Logging liefert auch die forensische Spur, die viele Verteidigungssicherheitsrahmenwerke erfordern, um nachzuweisen, dass Zugriffskontrollentscheidungen prüfbar sind.

Observability ohne Datenexfiltration: Cluster-interne Metriken und Tracing

Ein Service Mesh generiert automatisch umfangreiche Telemetrie von seinen Sidecar-Proxys: Pro-Dienst-Anfageraten, Fehlerraten aufgeschlüsselt nach HTTP-Status-Code und gRPC-Status, Latenz-Perzentile (p50, p95, p99), aktive Verbindungsanzahlen und TLS-Handshake-Metriken. In einer kommerziellen Cloud-Bereitstellung wird diese Telemetrie typischerweise an eine SaaS-Observability-Plattform weitergeleitet. In einem klassifizierten Militärcluster ist jede Telemetrie-Pipeline, die Daten außerhalb der Klassifizierungsgrenze sendet, ein potenzieller Exfiltrationsvektor und architektonisch verboten. Der gesamte Observability-Stack muss innerhalb der Cluster-Grenze bereitgestellt werden und muss selbst durch dieselben Mesh-Richtlinien zugriffskontrolliert werden, die den Anwendungsdatenverkehr regeln.

Der standardmäßige Cluster-interne Observability-Stack für ein Service Mesh besteht aus Prometheus für die Metrics-Erfassung, Grafana für die Visualisierung sowie Jaeger oder Tempo für verteiltes Tracing. Prometheus scrapt den Envoy-Stats-Endpunkt (Port 15090) oder den linkerd-proxy-Metriken-Endpunkt auf jedem gemeshten Pod in einem konfigurierbaren Intervall. Grafana verbindet sich ausschließlich mit den Cluster-internen Prometheus- und Loki-Instanzen – es sind keine externen Datenquellenverbindungen konfiguriert. Jaeger empfängt Trace-Spans, die der Envoy-Sidecar über das Zipkin- oder OpenTelemetry-Protokoll an einen Cluster-lokalen Collector-Endpunkt weiterleitet. Der gesamte persistente Speicher für Metriken, Traces und Protokolle verwendet Cluster-lokale PersistentVolumes, die durch verschlüsselte Blockspeicherung gesichert sind. Der Monitoring-Namespace selbst trägt eine NetworkPolicy, die den gesamten Ausgangsverkehr zu externen IP-Bereichen blockiert und es architektonisch unmöglich macht, dass Telemetrie den Cluster verlässt, selbst wenn eine falsch konfigurierte Pipeline eingeführt würde.

Für für Verteidigungsworkloads gehärtete Kubernetes-Cluster ist es erwähnenswert, dass der Observability-Stack ebenfalls aus air-gapped Registries bezogen werden muss. Prometheus-, Grafana-, Jaeger- und Loki-Images müssen mit verifizierten Digests in die interne Registry gespiegelt werden, bevor der Cluster hinter die Klassifizierungsgrenze gestellt wird. Image-Pull-Richtlinien müssen auf Never oder IfNotPresent gesetzt werden, in dem Verständnis, dass die Images niemals aus einer externen Quelle aktualisiert werden. Jede Aktualisierung des Observability-Stacks erfordert einen formalen Change-Management-Prozess, der aktualisierte Images durch das Air-Gap-Verfahren bringt, anstatt ein einfaches Helm-Chart-Upgrade gegen ein öffentliches Chart-Repository durchzuführen.

Sidecar-Overhead in ressourcenbeschränkten Verteidigungs-Edge-Clustern

Edge-Cluster, die nah an Operationen eingesetzt werden – auf Small-Form-Factor-Servern oder ruggedisierten Rechenplattformen mit 32–64 GB RAM und 4–8 Knoten laufend – haben ein Ressourcenbudget, das den Sidecar-Overhead zu einer echten technischen Einschränkung statt einer theoretischen Überlegung macht. Ein Istio-Envoy-Sidecar im Dauerbetrieb verbraucht 50–100 MB Resident Set Size und bis zu 0,5 vCPU während Hochdurchsatz-Perioden. Ein Cluster mit 40 Pods verbraucht 2–4 GB aggregierten Sidecar-Speicher, was etwa 6–12% des Gesamt-RAMs eines 32-GB-Clusters entspricht. Die Steuerungsebene selbst – istiod, Prometheus, Grafana, Jaeger – fügt weitere 2–4 GB hinzu, was den Gesamt-Mesh-Infrastruktur-Overhead auf 15–25% des Cluster-Speichers bringt, bevor Anwendungsworkloads berücksichtigt werden.

Drei Optionen reduzieren diesen Overhead bei eingeschränkten Bereitstellungen. Erstens ist Linkerd's Rust-basierter Proxy der effizienteste verfügbare Sidecar: 10–20 MB pro Pod statt 50–100 MB für Envoy, und Latenz-Overhead unter 1 ms pro Hop. Für Cluster, bei denen L7-Richtliniengranularitätsanforderungen durch Linkerd's Richtlinienmodell erfüllt werden können, sind die Speichereinsparungen erheblich. Zweitens eliminiert Isio's Ambient-Mesh-Modus (ab Istio 1.22 verfügbar) Pro-Pod-Sidecars vollständig und ersetzt sie durch einen Pro-Knoten-ztunnel-Proxy, der mTLS für alle Pods auf dem Knoten übernimmt. Der Ambient-Modus reduziert den Pro-Pod-Overhead auf nahezu null auf Kosten der Verlagerung der Richtliniendurchsetzung von Pro-Workload-Sidecars auf Pro-Knoten-Proxys, was eine etwas gröbere Richtliniengranularität für Workloads bietet, die Pro-Anfrage-Autorisierungsentscheidungen benötigen. Drittens bietet selektive Injektion – Injizierung von Sidecars nur in Pods, die L7-Richtliniendurchsetzung benötigen, und Verwendung von Cilium's eBPF-basierter L4-Verschlüsselung für den Rest – eine dritte Option zur Balance zwischen Durchsetzungsgranularität und Ressourcenverbrauch für heterogene Cluster-Workloads.

Die Wechselwirkung zwischen Sidecar-Ressourcenverbrauch und Secrets Management in Verteidigungs-CI/CD-Pipelines ist explizit erwähnenswert. Secret-Injektions-Sidecars (Vault Agent Injector, Secrets Store CSI Driver) fügen einen weiteren Container pro Pod hinzu. Ein Edge-Cluster, der sowohl einen Mesh-Sidecar als auch einen Secret-Injektions-Sidecar pro Anwendungs-Pod betreibt, hat zwei Infrastrukturcontainer für jeden Anwendungscontainer, was die Containeranzahl verdoppelt und 60–120 MB Infrastruktur-Overhead pro Pod-Paar hinzufügt. Eine Konsolidierung ist möglich: Der SPIRE-Agent kann sowohl als Mesh-Identitätsaussteller als auch als Workload-Secret-Liefermechanismus für Secrets dienen, die als SVID-autorisierte Vault-Rollen ausgedrückt werden können, wodurch der separate Secret-Injektions-Sidecar für diese Workloads entfällt.

Integration von Service-Mesh-Richtlinien mit RBAC und Secrets Management

Kubernetes-RBAC regelt, wer Kubernetes-API-Objekte lesen und ändern kann – einschließlich der AuthorizationPolicy-, PeerAuthentication- und Mesh-Konfigurationsressourcen, die die Sicherheitslage des Service Mesh definieren. Wenn die RBAC-Konfiguration einer breiten Menge von Principals erlaubt, AuthorizationPolicy-Objekte zu ändern, kann die Zugriffskontrollschicht des Mesh von jedem dieser Principals geschwächt werden. Eine korrekte Verteidigungsbereitstellung behandelt Mesh-Richtlinienmanifeste als hochwertige Sicherheitsobjekte: Nur das CI/CD-Dienstkonto, das Manifeste aus dem versionskontrollierten Richtlinienrepository anwendet, sollte Schreibzugriff auf AuthorizationPolicy- und PeerAuthentication-Ressourcen haben, und nur Cluster-Administratoren sollten SPIRE-Registrierungseinträge ändern können. Alle anderen Principals – einschließlich einzelner Anwendungsdienstkonten – sollten nur Lesezugriff oder keinen Zugriff auf diese Objekte haben.

Die Beziehung zwischen der Mesh-Identitätsschicht und der Secrets-Management-Schicht ist bidirektional. Das Mesh verwendet SPIFFE-SVIDs zur Authentifizierung von Dienst-zu-Dienst-Aufrufen auf der Transportschicht. Secrets Management (Vault, Kubernetes Secrets Store CSI Driver) verwendet dieselben SVID-basierten Identitäten, um zu bestimmen, welche Workloads welche Secrets auf der Anwendungsschicht erhalten dürfen. Ein Workload mit der SPIFFE-ID spiffe://cluster.local/ns/fusion/sa/data-processor kann einer Vault-Rolle zugeordnet werden, die Lesezugriff auf genau die Datenbankzugangsdaten gewährt, die dieser Dienst benötigt – und nichts anderes. Das bedeutet, dass das Mesh-Identitätssystem und das Secrets-Delivery-System eine einzige autoritative Quelle der Workload-Identität teilen, was das Risiko eines Mismatches eliminiert, bei dem einem Workload Netzwerkzugriff erlaubt wird, aber nicht die Secrets, die er für dessen Nutzung benötigt, oder umgekehrt. Die Aufrechterhaltung dieser Übereinstimmung erfordert, dass SPIRE-Registrierungseinträge, Vault-Rollendefinitionen und Mesh-AuthorizationPolicy-Manifeste gemeinsam aktualisiert werden, wenn ein Dienst hinzugefügt, geändert oder außer Betrieb genommen wird.

Audit-Logging verbindet die drei Systeme für Compliance und Incident Response. Der Mesh-Sidecar protokolliert jede Zugriffsentscheidung – Erlaubnis oder Ablehnung – mit dem verifizierten Quell-SVID, Ziel, Operation und Zeitstempel. Vault protokolliert jeden Secret-Zugriff mit der anfragenden Identität und dem aufgerufenen Secret-Pfad. Der Kubernetes-API-Server-Audit-Log zeichnet jeden RBAC-gesteuerten API-Aufruf auf. Zusammen liefern diese drei Log-Streams eine vollständige Prüfspur von „welcher Netzwerkaufruf wurde getätigt" über „welche Secrets wurden infolgedessen aufgerufen" bis „wer hat die Richtlinie geändert, die beides regelte". Für Verteidigungsumgebungen, die unter formalen Akkreditierungsanforderungen operieren, ist diese Nachverfolgbarkeit über die Identitäts-, Zugriffskontroll- und Secrets-Schichten hinweg oft eine unverzichtbare Compliance-Anforderung und nicht eine operative Annehmlichkeit.