Cilium mTLS-Verschlüsselung (öffentliche Vorschau)

Die Cilium mTLS-Verschlüsselung bietet transparente, gegenseitige TLS-Verschlüsselung (mTLS) und Authentifizierung für Pod-zu-Pod-Datenverkehr in Kubernetes, ohne dass Anwendungsänderungen erforderlich sind oder zusätzliche Netzwerkstapel eingeführt werden müssen.

Sie stellt sicher, dass sowohl die Quell- als auch die Zielarbeitsauslastung kryptografisch authentifiziert werden, bevor datenverkehrsgetauscht wird. Dieser Ansatz ermöglicht ein Zero-Trust-Netzwerkmodell für Kubernetes-Workloads.

Die gesamte Verschlüsselung und Authentifizierung erfolgt unterhalb der Anwendungsschicht, was bedeutet, dass Workloads nicht geändert, neu erstellt oder neu gestartet werden müssen, um von mTLS zu profitieren.

Die Cilium mTLS-Verschlüsselung für AKS ist Teil des Advanced Container Networking Services (ACNS) -Featuresatzes, und die Implementierung basiert auf Cilium.

Von Bedeutung

AKS-Vorschaufunktionen sind auf Selbstbedienungsbasis und freiwillig verfügbar. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Architektur

Auf einer übergeordneten Ebene sichert Cilium mTLS den Netzwerkverkehr durch die Kombination von Identitätsausstellung, transparentem Abfangen des Datenverkehrs und Erzwingung der Verschlüsselung auf Arbeitslast-Ebene.

Jeder Workload wird eine kryptografische Identität zugewiesen, die von Kubernetes-Attributen wie Namespace und ServiceAccount abgeleitet wurde. Wenn pod-to-pod-TCP-Datenverkehr initiiert wird, wird der Datenverkehr transparent auf Knotenebene abgefangen. Der Datenverkehr wird dann mithilfe von gegenseitigem TLS authentifiziert und verschlüsselt, bevor er an die Zielarbeitsauslastung weitergeleitet wird.

Das System besteht aus drei kooperierenden Komponenten:

SPIRE – Bietet Workload-Identität und Zertifikatausstellung.
ztunnel - Erzwingt mTLS in der Datenebene.
Cilium – Installiert IPTables-Regeln, die ausgehenden Datenverkehr an ztunnel am Port 15001 umleiten.

Gemeinsam stellen diese Komponenten sicher, dass die Authentifizierung und Verschlüsselung transparent und konsistent im gesamten Cluster erfolgt.

Identitäts- und Authentifizierungsmodell

Cilium mTLS verwendet die gegenseitige Authentifizierung basierend auf der SPIFFE Workload-Identität.

Jeder Workload erhält eine SPIFFE-Identität (SVID), die abgeleitet wird von:

Kubernetes-Namespace
Kubernetes ServiceAccount

Wenn eine Workload eine Verbindung initiiert:

Der Quell-Ztunnel ruft eine gültige SVID für den Workload ab.
Der Ziel-Ztunnel überprüft die dargestellte Identität.
Beide Seiten führen eine gegenseitige Überprüfung durch, bevor der Verkehr fließen darf.

Authentifizierungsentscheidungen basieren auf der Workload-Identität und nicht auf dem Netzwerkstandort. Mit diesem Design wird Folgendes sichergestellt:

Nur authentifizierte Workloads können kommunizieren.
Die Identität bleibt bei Umplanung und Skalierung konsistent.
Die Vertrauensstellung hängt nicht von der IP-Adressierung oder Netzwerktopologie ab.

Verschlüsselungsfluss

Nach erfolgreicher Authentifizierung wird der Datenverkehr mithilfe von gegenseitigem TLS geschützt.

Datenverkehr wurde im Pod-Netzwerknamespace abgefangen und an die lokale ztunnel-Instanz umgeleitet.
Der Quell-Ztunnel initiiert eine mTLS-Sitzung mit dem Ziel ztunnel.
Zertifikate werden ausgetauscht und validiert.
Anwendungsdaten werden vor der Übertragung verschlüsselt.
Der Ziel-Ztunnel entschlüsselt den Datenverkehr und liefert ihn an den Ziel-Pod.

Jedes Paket von einem registrierten Pod wird verschlüsselt. Es gibt kein Klartextfenster und keine gelöschten ersten Pakete. Die Verbindung wird von ztunnel inline gehalten, bis der mTLS-Tunnel eingerichtet wird, dann fließt der Datenverkehr bidirektional über einen HBONE-Tunnel (HTTP/2 CONNECT).

Kernkomponenten

SPIRE (Identität und Vertrauen)

SPIRE (SPIFFE Runtime Environment) ist für die Workload-Identitäts- und Zertifikatverwaltung verantwortlich. SPIRE verfügt über zwei Hauptkomponenten: den SPIRE-Server und den SPIRE-Agent.

Der SPIRE-Server fungiert als Clusterzertifizierungsstelle (Cluster Certificate Authority, CA). Es stellt kurzlebige X.509-Zertifikate (SVIDs) nur für Workloads aus, die berechtigt sind, Identitäten zu empfangen. Es verwendet Kubernetes-native Attestierung, wobei die Identität an Attribute wie Namespace und ServiceAccount gebunden wird, statt an Netzwerkeigenschaften wie IP-Adressen.

Auf jedem Knoten ist der SPIRE-Agent dafür verantwortlich, den Knoten auf dem SPIRE-Server zu attestieren und Zertifikate im Auftrag lokaler Workloads abzurufen. Workloads kommunizieren nur mit dem SPIRE-Agent und nie direkt mit dem SPIRE-Server.

SPIRE stellt sicher, dass jede Workload-Identität:

Kryptografisch verifizierbar.
Automatisch ausgegeben und rotiert.
Gebunden an Kubernetes-Grundtypen, nicht an IP-Adressen.
Stabil bei Pod-Neustarts und Ereignissen zur Neuplanung.

Diese Identitätsbasis ermöglicht starke, topologieunabhängige Vertrauensentscheidungen.

Ztunnel (mTLS-Datenebene)

Ztunnel ist ein einfacher Layer 4-Proxy auf Knotenebene, der für die Erzwingung von mTLS zwischen Workloads verantwortlich ist. Es wird als DaemonSet mit einer Instanz pro Knoten ausgeführt, wodurch die Notwendigkeit von Sidecar-Proxys für jeden Pod entfällt.

Wenn ein Workload eine TCP-Verbindung initiiert, baut ztunnel eine gegenseitig authentifizierte TLS-Sitzung mit der ztunnel-Instanz des Peer-Knotens auf. Es verwendet Zertifikate, die von SPIRE abgerufen wurden, um beide Seiten der Verbindung zu authentifizieren, bevor Datenverkehr fließen kann.

Ztunnel erzwingt die folgenden Garantien:

Beide Seiten einer Verbindung müssen gültige Workloadzertifikate vorlegen.
Zertifikate werden für die Clustervertrauensdomäne überprüft.
Der Datenverkehr wird immer auf dem Draht verschlüsselt.
Für registrierte Workloads ist kein Klartext-Fallback zulässig.

Durch die Zentralisierung der mTLS-Erzwingung auf der Knotenebene bietet ztunnel hohe Sicherheitsmerkmale, ohne den Betriebsaufwand pro Pod zu erhöhen.

Cilium (Umleitungsregeln und Pod-Registrierung)

Cilium ist dafür verantwortlich, mTLS transparent für Anwendungen zu machen.

Wenn ein Namespace mit "io.cilium/mtls-enabled=true" gekennzeichnet ist, registriert der Cilium-Agent alle Pods in diesem Namespace. Es tritt in den Netzwerk-Namespace jedes Pods ein und installiert iptables-Regeln, die den ausgehenden Datenverkehr an ztunnel auf Port 15001 umleiten.

Cilium übergibt auch Workload-Metadaten, wie z. B. die Pod-UID, an ztunnel und integriert sich mit dem Cilium-Operator, um Workloadidentitäten bei SPIRE zu registrieren.

Aus Sicht der Anwendung verwendet die Kommunikation weiterhin standardmäßige TCP-Sockets. Verschlüsselung und Authentifizierung werden vollständig unterhalb der Anwendungsebene erzwungen, sodass keine Codeänderungen erforderlich sind.

Bereichs- und Vertrauensgrenzen

Namespace-Eintragung

Cilium mTLS ist optional und auf Namespace-Ebene festgelegt. Ein Namespace muss explizit bezeichnet werden, um die MTLS-Erzwingung zu aktivieren. Nach der Aktivierung unterliegen alle Pods in diesem Namespace der obligatorischen Authentifizierung und Verschlüsselung.

Pods in nicht registrierten Namespaces sind nicht betroffen. Dieses Design ermöglicht die inkrementelle Einführung und mehrstufige Einführung in allen Umgebungen.

Erzwingungsmodell

Verschlüsselung wird nur angewendet, wenn beide Pods registriert sind. Der Datenverkehr zwischen angemeldeten und nicht angemeldeten Workloads wird im Klartext fortgesetzt, ohne dass es zu Problemen mit der Konnektivität oder schwerwiegenden Ausfällen kommt.

Quelle	Bestimmungsort	Ergebnis
Eingeschrieben	Eingeschrieben	Verschlüsselt (mTLS über HBONE)
Eingeschrieben	Nicht registriert	Klartext-Durchleitung
Nicht registriert	Eingeschrieben	Nur-Text (erfasst von ztunnel, aber nicht verschlüsselt)
Nicht registriert	Nicht registriert	Normaler Cilium-Datenpfad (keine Ztunnelbeteiligung)

Überlegungen und Einschränkungen

Das Feature ist nur für Cluster verfügbar, die Azure CNI verwenden, das von Cilium mit aktiviertem Advanced Container Networking Services (ACNS) unterstützt wird.
mTLS ist auf Namespaceebene aktiviert. Alle Pods in einem registrierten Namespace nehmen an mTLS teil. Opt-In oder Opt-Out auf Pod-Ebene wird nicht unterstützt.
Cilium mTLS schützt zurzeit den TCP-basierten Pod-zu-Pod-Datenverkehr. Es verschlüsselt oder authentifiziert derzeit keine anderen Protokolle, einschließlich UDP.
In der aktuellen Phase wird die Durchsetzung von L4/L7-Netzwerkrichtlinien mit mTLS nicht unterstützt.
Sie können keine benutzerdefinierte CA mitbringen. SPIRE fungiert als Clusterzertifizierungsstelle und verwaltet die Ausstellung und Erneuerung von Zertifikaten.
Das Aktivieren von mTLS und WireGuard auf demselben Cluster wird nicht unterstützt.
Das Aktivieren der Istio- und Cilium mTLS-Verschlüsselung wird nicht unterstützt.
Die mTLS-Verschlüsselung für clusterübergreifenden Datenverkehr wird nicht unterstützt.
Die Integration erfordert iptables-Unterstützung im Kernel und kann nicht mit Umgebungen verwendet werden, die iptables nicht unterstützen (z. B. einige minimale Containerlaufzeiten).
Pods ohne Netzwerknamespacepfad (z. B. hostnetzwerkierte Pods) können nicht in ztunnel registriert und während des Registrierungsprozesses ausgeschlossen werden.

Preise