Cilium mTLS-kryptering (offentlig förhandsversion)

Cilium mTLS-kryptering ger transparent, ömsesidig TLS-kryptering (mTLS) och autentisering för podd-till-pod-trafik i Kubernetes utan att kräva programändringar eller införa någon extra nätverksstack.

Det säkerställer att både käll- och målarbetsbelastningarna är kryptografiskt autentiserade innan någon trafik utbyts. Den här metoden möjliggör en nätverksmodell med noll förtroende för Kubernetes-arbetsbelastningar.

All kryptering och autentisering sker under programnivån, vilket innebär att arbetsbelastningar inte behöver ändras, återskapas eller startas om för att dra nytta av mTLS.

Cilium mTLS-kryptering för AKS är en del av acns-funktionsuppsättningen (Advanced Container Networking Services) och implementeringen baseras på Cilium.

Arkitektur

På hög nivå skyddar Cilium mTLS trafiken genom att kombinera identitetsutfärdande, transparent trafikavlyssning och kryptering på arbetsbelastningsnivå.

Varje arbetsbelastning tilldelas en kryptografisk identitet som härleds från Kubernetes-attribut som namnrymd och ServiceAccount. När TCP-trafik från podd till podd initieras fångas trafiken transparent upp på nodnivå. Trafiken autentiseras och krypteras sedan med hjälp av ömsesidig TLS innan den vidarebefordras till målarbetsbelastningen.

Systemet består av tre samarbetskomponenter:

• SPIRE – Tillhandahåller arbetsbelastningsidentifikation och certifikatutfärdande.
• ztunnel – Framtvingar mTLS i dataplanet.
• Cilium – Installerar iptables-regler som omdirigerar utgående trafik till ztunnel på port 15001.

Tillsammans säkerställer dessa komponenter att autentisering och kryptering sker transparent och konsekvent i klustret.

Identitets- och autentiseringsmodell

Cilium mTLS använder ömsesidig autentisering baserat på SPIFFE-arbetsbelastningsidentitet.

Varje arbetsbelastning tilldelas en SPIFFE-identitet (SVID) som härleds från:

• Kubernetes-namnområde
• Kubernetes ServiceAccount

När en arbetsbelastning initierar en anslutning:

1. Källan ztunnel hämtar en giltig SVID för arbetsbelastningen.
2. Z-tunneln vid målet bekräftar den presenterade identiteten.
3. Båda sidor slutför ömsesidig verifiering innan trafiken tillåts flöda.

Autentiseringsbeslut baseras på arbetsbelastningsidentitet snarare än nätverksplats. Den här designen säkerställer att:

• Endast autentiserade workloads kan kommunicera.
• Identiteten förblir konsekvent över omplanering och skalning.
• Förtroende är inte beroende av IP-adressering eller nätverkstopologi.

Krypteringsflöde

Efter lyckad autentisering skyddas trafiken med hjälp av ömsesidig TLS.

1. Trafiken stoppades i poddnätverkets namnområde och omdirigerades till den lokala ztunnelinstansen.
2. Käll-ztunneln initierar en mTLS-session med mål-ztunneln.
3. Certifikat utbyts och verifieras.
4. Programdata krypteras före överföring.
5. Destinations ztunnel dekrypterar trafiken och levererar den till målpodden.

Varje paket från en registrerad podd krypteras. Det finns inget klartextfönster och inga borttagna första paket. Anslutningen hålls kvar i linje av ztunnel tills mTLS-tunneln har upprättats, och därefter går trafiken i båda riktningarna genom en HBONE-tunnel (HTTP/2 CONNECT).

Kärnkomponenter

SPIRE (identitet och förtroende)

SPIRE (SPIFFE Runtime Environment) ansvarar för arbetslastidentitet och certifikathantering. SPIRE har två huvudkomponenter: SPIRE-servern och SPIRE-agenten.

SPIRE-servern fungerar som klustercertifikatutfärdare (CA). Den utfärdar kortlivade X.509-certifikat (SVID) till endast arbetsbelastningar som tillåts ta emot identiteter. Den använder Kubernetes-inbyggd attestering och binder identiteten till attribut som namnrymd och ServiceAccount i stället för till nätverksegenskaper som IP-adresser.

På varje nod ansvarar SPIRE-agenten för attestera noden till SPIRE-servern och hämta certifikat för lokala arbetsbelastningar. Arbetslaster kommunicerar endast med SPIRE-agenten och aldrig direkt med SPIRE-servern.

SPIRE säkerställer att varje arbetsbelastningsidentitet är:

• Kryptografiskt verifierbar.
• Utfärdas och roteras automatiskt.
• Bunden till Kubernetes-primitiver, inte IP-adresser.
• Stabilitet vid omstart av poddar och vid omplaneringar.

Den här identitetsgrunden möjliggör starka, topologioberoende förtroendebeslut.

Ztunnel (mTLS-dataplan)

Ztunnel är en enkel Layer 4-proxy på nodnivå som ansvarar för att framtvinga mTLS mellan arbetsbelastningar. Den körs som en DaemonSet med en instans per nod, vilket eliminerar behovet av sidecar-proxy för varje podd.

När en arbetsbelastning initierar en TCP-anslutning upprättar ztunnel en ömsesidigt autentiserad TLS-session med peer-nodens ztunnelinstans. Den använder certifikat som hämtats från SPIRE för att autentisera båda sidor av anslutningen innan trafik tillåts flöda.

Ztunnel tillämpar följande garantier:

• Båda sidor av en anslutning måste innehålla giltiga arbetsbelastningscertifikat.
• Certifikat verifieras mot klusterförtroendedomänen.
• Trafiken krypteras alltid på kabeln.
• Ingen återställning i klartext tillåts för registrerade arbetsbelastningar.

Genom att centralisera mTLS-tillämpning på nodnivå ger ztunnel starka säkerhetsegenskaper utan att öka driftkostnaderna per podd.

Cilium (omdirigeringsregler och poddregistrering)

Cilium ansvarar för att göra mTLS transparent för program.

När ett namnområde är märkt med "io.cilium/mtls-enabled=true" registrerar Cilium-agenten alla poddar i det namnområdet. Den anger varje podds nätverksnamnområde och installerar iptables-regler som omdirigerar utgående trafik till ztunnel på port 15001.

Cilium skickar även arbetsbelastningsmetadata, till exempel Pod UID, till ztunnel och integreras med Cilium-operatorn för att registrera arbetsbelastningsidentiteter med SPIRE.

Från programmets perspektiv fortsätter kommunikationen att använda standard-TCP-socketar. Kryptering och autentisering framtvingas helt under programlagret, vilket inte kräver några kodändringar.

Omfångs- och förtroendegränser

Namnområdesregistrering

Cilium mTLS är valbar och tillämpas på namnområdesnivå. Ett namnområde måste uttryckligen märkas för att aktivera mTLS-tillämpning. När de är aktiverade omfattas alla poddar i det namnområdet av obligatorisk autentisering och kryptering.

Poddar i icke-registrerade namnområden påverkas inte. Den här designen möjliggör inkrementell distribution och stegvis implementering i olika miljöer.

Tvingande modell

Kryptering tillämpas endast när båda poddarna har registrerats. Trafiken mellan registrerade och icke-registrerade arbetsbelastningar fortsätter i klartext utan att orsaka anslutningsproblem eller hårda fel.

Överväganden och begränsningar

• Funktionen är endast tillgänglig i kluster med Azure CNI som drivs av Cilium med ACNS (Advanced Container Networking Services) aktiverat.
• mTLS är aktiverat på namnområdesnivå. Alla poddar i ett registrerat namnområde deltar i mTLS. Opt-in eller opt-out på poddnivå stöds inte.
• Cilium mTLS skyddar för närvarande TCP-baserad podd-till-pod-trafik. Den krypterar eller autentiserar för närvarande inte andra protokoll, inklusive UDP.
• I den aktuella fasen stöds inte tillämpning av nätverkspolicyer för L4/L7 med mTLS.
• Du kan inte använda en anpassad certifikatutfärdare. SPIRE fungerar som klustercertifikatutfärdare och hanterar utfärdande och rotation av certifikat.
• Det går inte att aktivera både mTLS och WireGuard i samma kluster.
• Det går inte att aktivera både Istio- och Cilium mTLS-kryptering.
• mTLS-kryptering för trafik mellan kluster stöds inte.
• Integreringen kräver stöd för iptables i kerneln och kan inte användas med miljöer som inte stöder iptables (till exempel några minimala containerkörningar).
• Poddar utan nätverksnamnområdessökväg (till exempel värdnätverkspoddar) kan inte registreras i ztunnel och exkluderas under registreringsprocessen.

Pricing

Nästa steg

• Lär dig hur du använder Cilium mTLS-kryptering på AKS.

• För mer information om Avancerade containernätverkstjänster för Azure Kubernetes Service (AKS), se Vad är avancerade containernätverkstjänster för Azure Kubernetes Service (AKS)?.