Cilium mTLS-versleuteling (openbare preview)

Cilium mTLS-versleuteling biedt transparante, wederzijdse TLS-versleuteling (mTLS) en verificatie voor pod-naar-pod-verkeer in Kubernetes zonder dat toepassingswijzigingen nodig zijn of een extra netwerkstack hoeft te introduceren.

Het zorgt ervoor dat zowel de bron- als doelworkloads cryptografisch worden geverifieerd voordat verkeer wordt uitgewisseld. Deze benadering maakt een netwerkmodel met nul vertrouwen mogelijk voor Kubernetes-workloads.

Alle versleuteling en verificatie vindt plaats onder de toepassingslaag, wat betekent dat workloads niet hoeven te worden gewijzigd, opnieuw hoeven te worden opgebouwd of opnieuw hoeven te worden opgestart om te profiteren van mTLS.

Cilium mTLS-versleuteling voor AKS maakt deel uit van de functieset Advanced Container Networking Services (ACNS) en de implementatie is gebaseerd op Cilium.

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals het is' en 'voor zover beschikbaar' en zijn uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning naar best vermogen. Zodoende zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

Architectuur

Op hoog niveau beveiligt Cilium mTLS verkeer door identiteitsuitgifte, transparante verkeersonderschepping en versleuteling op workloadniveau te combineren.

Aan elke workload wordt een cryptografische identiteit toegewezen die is afgeleid van Kubernetes-kenmerken, zoals naamruimte en ServiceAccount. Wanneer TCP-verkeer van pod naar pod wordt gestart, wordt het verkeer op transparante wijze onderschept op het niveau van de node. Het verkeer wordt vervolgens geverifieerd en versleuteld met behulp van wederzijdse TLS voordat het wordt doorgestuurd naar de doelworkload.

Het systeem bestaat uit drie medewerkende onderdelen:

SPIRE : biedt workloadidentiteit en certificaatuitgifte.
ztunnel - Dwingt mTLS af in het gegevensvlak.
Cilium : installeert iptables-regels waarmee uitgaand verkeer wordt omgeleid naar ztunnel op poort 15001.

Samen zorgen deze onderdelen ervoor dat verificatie en versleuteling transparant en consistent plaatsvinden in het cluster.

Identiteits- en verificatiemodel

Cilium mTLS maakt gebruik van wederzijdse verificatie op basis van spiffe-workloadidentiteit.

Aan elke workload wordt een SPIFFE-identiteit (SVID) toegewezen die is afgeleid van:

Kubernetes-naamruimte
Kubernetes ServiceAccount

Wanneer een workload een verbinding initieert:

De bron ztunnel haalt een geldige SVID op voor de workload.
De bestemmings-ztunnel valideert de gepresenteerde identiteit.
Beide zijden voltooien wederzijdse verificatie voordat verkeer mag stromen.

Verificatiebeslissingen zijn gebaseerd op workloadidentiteit in plaats van netwerklocatie. Dit ontwerp zorgt ervoor dat:

Alleen geverifieerde workloads kunnen communiceren.
Identiteit blijft consistent bij het opnieuw plannen en schalen.
Vertrouwen is niet afhankelijk van IP-adressering of netwerktopologie.

Versleutelingsstroom

Nadat de verificatie is geslaagd, wordt verkeer beveiligd met behulp van wederzijdse TLS.

Verkeer dat binnen de pod-netwerknaamruimte wordt onderschept en naar het lokale ztunnel-exemplaar wordt omgeleid.
De bron ztunnel initieert een mTLS-sessie met de doel-ztunnel.
Certificaten worden uitgewisseld en gevalideerd.
Toepassingsgegevens worden versleuteld voordat ze worden verzonden.
De doelztunnel decodeert het verkeer en levert het aan de doelpod.

Elk pakket van een geregistreerde pod wordt versleuteld. Er is geen venster met platte tekst en geen weggelaten eerste pakketten. De verbinding wordt inline gehouden door ztunnel totdat de mTLS-tunnel tot stand is gebracht, waarna verkeer bidirectioneel stroomt via een HBONE-tunnel (HTTP/2 CONNECT).

Kernonderdelen

SPIRE (identiteit en vertrouwen)

SPIRE (SPIFFE Runtime Environment) is verantwoordelijk voor het beheer van workloadidentiteit en certificaat. SPIRE heeft twee belangrijke onderdelen: de SPIRE-server en de SPIRE-agent.

De SPIRE-server fungeert als de clustercertificeringsinstantie (CA). Er worden kortdurende X.509-certificaten (SVID's) alleen uitgegeven aan workloads die identiteiten mogen ontvangen. Het maakt gebruik van Kubernetes-native attestation, waarbij identificatie wordt gebonden aan attributen zoals de namespace en ServiceAccount in plaats van aan netwerkeigenschappen zoals IP-adressen.

Op elk knooppunt is de SPIRE-agent verantwoordelijk voor het attesteren van het knooppunt aan de SPIRE-server en het ophalen van certificaten namens lokale workloads. Workloads communiceren alleen met de SPIRE-agent en nooit rechtstreeks met de SPIRE-server.

SPIRE zorgt ervoor dat elke workloadidentiteit:

Cryptografisch verifieerbaar.
Automatisch uitgegeven en gerouleerd.
Gebonden aan Kubernetes-primitieven, niet IP-adressen.
Stabiel tijdens het opnieuw opstarten van pods en het opnieuw plannen van gebeurtenissen.

Deze identiteitsbasis maakt sterke, topologie-onafhankelijke vertrouwensbeslissingen mogelijk.

Ztunnel (mTLS-gegevensvlak)

Ztunnel is een lichtgewicht laag 4-proxy op knooppuntniveau die verantwoordelijk is voor het afdwingen van mTLS tussen workloads. Het wordt uitgevoerd als een DaemonSet, met één exemplaar per knooppunt, waardoor de noodzaak voor sidecar-proxy's per pod wordt weggenomen.

Wanneer een workload een TCP-verbinding initieert, brengt ztunnel een wederzijds geverifieerde TLS-sessie tot stand met het ztunnel-exemplaar van het peerknooppunt. Het maakt gebruik van certificaten die zijn verkregen van SPIRE om beide zijden van de verbinding te verifiëren voordat verkeer kan stromen.

Ztunnel dwingt de volgende garanties af:

Beide zijden van een verbinding moeten geldige workloadcertificaten bevatten.
Certificaten worden geverifieerd op basis van het clustervertrouwensdomein.
Verkeer wordt altijd versleuteld op de kabel.
Platte tekst als terugvaloptie is niet toegestaan voor geregistreerde workloads.

Door mTLS-afdwinging op knooppuntniveau te centraliseren, biedt ztunnel sterke beveiligingseigenschappen zonder de operationele overhead per pod te verhogen.

Cilium (omleidingsregels en podinschrijving)

Cilium is verantwoordelijk voor het transparant maken van mTLS voor toepassingen.

Wanneer een naamruimte is gelabeld met 'io.cilium/mtls-enabled=true', registreert de Cilium-agent alle pods in die naamruimte. Het voert de netwerknaamruimte van elke pod in en installeert iptables-regels die uitgaand verkeer omleiden naar ztunnel op poort 15001.

Cilium geeft ook metagegevens van workloads, zoals de Pod UID, door aan ztunnel en integreert met de Cilium-operator om workloadidentiteiten te registreren bij SPIRE.

Vanuit het perspectief van de toepassing wordt de communicatie voortgezet met behulp van standaard TCP-sockets. Versleuteling en verificatie worden volledig afgedwongen onder de toepassingslaag, waarvoor geen codewijzigingen zijn vereist.

Bereik- en vertrouwensgrenzen

Naamruimte-inschrijving

Cilium mTLS is vrijwillig en wordt toegepast op het niveau van de naamruimte. Een naamruimte moet expliciet worden gelabeld om mTLS-afdwinging mogelijk te maken. Zodra deze optie is ingeschakeld, zijn alle pods binnen die naamruimte onderworpen aan verplichte verificatie en versleuteling.

Pods in niet-geregistreerde naamruimten worden niet beïnvloed. Dit ontwerp maakt incrementele implementatie en gefaseerde acceptatie mogelijk in omgevingen.

Afdwingingsmodel

Versleuteling wordt alleen toegepast wanneer beide pods zijn geregistreerd. Verkeer tussen ingeschreven en niet-ingeschreven workloads gaat verder in platte tekst zonder connectiviteitsproblemen of ernstige storingen te veroorzaken.

bron	Bestemming	Resultaat
Ingeschreven	Ingeschreven	Versleuteld (mTLS via HBONE)
Ingeschreven	Niet-ingeschreven	Passthrough van platte tekst
Niet-ingeschreven	Ingeschreven	Plaintext (vastgelegd door ztunnel, maar niet versleuteld)
Niet-ingeschreven	Niet-ingeschreven	Normaal Ciliumdatapath (geen ztunnel-betrokkenheid)

Overwegingen en beperkingen

De functie is alleen beschikbaar voor clusters die gebruikmaken van Azure CNI, mogelijk gemaakt door Cilium, waarvoor ACNS (Advanced Container Networking Services) is ingeschakeld.
mTLS is ingeschakeld op naamruimteniveau. Alle pods in een ingeschreven naamruimte nemen deel aan mTLS. Opt-in of opt-out op niveau van de pod wordt niet ondersteund.
Cilium mTLS beveiligt momenteel tcp-pod-to-pod-verkeer. Het versleutelt of verifieert momenteel geen andere protocollen, waaronder UDP.
In de huidige fase wordt het afdwingen van L4/L7-netwerkbeleid niet ondersteund met mTLS.
U kunt geen aangepaste CA meenemen. SPIRE fungeert als de certificeringsinstantie van het cluster en beheert certificaatuitgifte en rotatie.
Het inschakelen van zowel mTLS als WireGuard op hetzelfde cluster wordt niet ondersteund.
Het inschakelen van zowel Istio- als Cilium mTLS-versleuteling wordt niet ondersteund.
mTLS-versleuteling voor verkeer tussen clusters wordt niet ondersteund.
De integratie vereist iptables-ondersteuning in de kernel en kan niet worden gebruikt met omgevingen die iptables niet ondersteunen (zoals enkele minimale containerruntimes).
Pods zonder netwerknaamruimtepad (zoals hostnetwerkpods) kunnen niet worden ingeschreven bij ztunnel en worden uitgesloten tijdens het inschrijvingsproces.

prijsstelling