Översikt över Säkerhet för Azure Kubernetes-programnätverk (förhandsversion)

Azure Kubernetes Application Network skyddar kommunikationen mellan tjänster i anslutna AKS-kluster (Azure Kubernetes Service) via automatisk ömsesidig TLS (mTLS) och identitetsbaserad auktorisering. Den utfärdar arbetsbelastningsidentiteter och hanterar certifikatutfärdande, rotation och validering för att aktivera krypterad, autentiserad och explicit auktoriserad tjänst-till-tjänst-kommunikation utan manuell konfiguration, med FIPS-kompatibel kryptering under överföring.

Den här artikeln innehåller en översikt över säkerhetsfunktionerna i Azure Kubernetes Application Network, inklusive mTLS, arbetsbelastningsidentiteter, certifikathantering och auktoriseringsprinciper. Den beskriver också begränsningar och nästa steg för att implementera säker kommunikation i din Azure Kubernetes Application Network-miljö.

Begränsningar

• Certifikat utfärdas för närvarande av en Azure Kubernetes Application Network-hanterad certifikatutfärdare (CA) och är inte kopplade till en offentlig certifikatutfärdare.

mTLS

Application Network använder mTLS för att tillhandahålla identitetsbaserad, krypterad kommunikation mellan arbetsbelastningar. Varje tjänst i ett programnätverksanslutet kluster får automatiskt ett certifikat som gör att den kan bevisa sin identitet och upprätta betrodda, krypterade anslutningar med andra tjänster i samma programnätverk. Kryptering under överföring använder FIPS-kompatibel kryptografi.

mTLS-migreringsstrategi

Application Network tillåter för närvarande både krypterad och okrypterad trafik. Den här metoden säkerställer att befintliga arbetsbelastningar fortsätter att fungera normalt medan nya eller uppdaterade arbetsbelastningar automatiskt använder mTLS för säker kommunikation. Det innebär att du kan använda mTLS för säker kommunikation mellan dina arbetsbelastningar utan driftstopp. När migreringen är klar kan du ändra till strikt läge så att autentiseringen tillämpas.

Fördelar med mTLS i Azure Kubernetes Application Network

mTLS i Azure Kubernetes Application Network hjälper dig:

• Skydda data under överföring: All tjänst-till-tjänst-trafik kan krypteras automatiskt (FIPS-kompatibel).
• Verifiera tjänstidentitet: Varje arbetsbelastning har ett unikt programnätverkshanterat rotcertifikat och mellanliggande certifikat.
• Förenkla åtgärder: Programnätverket hanterar certifikatutfärdare, rotation och återkallande för användare.

certifikathantering

Azure Kubernetes Application Network tillhandahåller certifikathantering som backas upp av Azure Key Vault och som utfärdar och underhåller de certifikat som används för mTLS. Den här tjänsten upprättar en delad förtroendegräns för alla AKS-kluster som är anslutna till samma programnätverksresurs.

Application Network hanterar automatiskt hela certifikatets livscykel för rotcertifikat och mellanliggande certifikat, inklusive etablering, förnyelse och rotation. Detta säkerställer att arbetsbelastningsidentiteter förblir giltiga och kommunikationen förblir säker över tid. Du behöver inte skapa, lagra eller rotera certifikat manuellt.

Följande diagram illustrerar certifikathierarkin i Application Network, som visar hur rotcertifikatutfärdare, mellanliggande certifikatutfärdare och arbetsbelastningscertifikat struktureras för att upprätta förtroende mellan anslutna kluster:

Certifikathierarki och livscykel

När en programnätverksresurs skapas etableras en rotcertifikatutfärdare för att fungera som förtroendeankare för programnätverket. När ett AKS-kluster ansluter till programnätverket som medlem utfärdar Programnätverk ett mellanliggande certifikat för den medlemmen som signerats av rotcertifikatutfärdare för programnätverk. Varje anslutet AKS-kluster använder sitt programnätverkshanterade mellanliggande certifikat för att utfärda kortlivade arbetsbelastningscertifikat till arbetsbelastningar i klustret.

Alla arbetsbelastningscertifikat ärver förtroende från programnätverkets rotcertifikatutfärdare och upprätthåller en enhetlig förtroendegräns över resursen. Rotationen av rotcertifikat och mellanliggande certifikat hanteras transparent för användare utan att orsaka driftstopp eller trafikstörningar. Den här hanterade hierarkin garanterar konsekvent, verifierbart förtroende för alla kluster i ett programnätverk samtidigt som giltigheten för varje certifikat upprätthålls automatiskt.

Från valfritt medlemskluster kan du hämta rot-CA-certifikatet från config map istio-root-cert under namespace applink-system.

Certifikattyper och rotationsperioder

Identitet och auktorisering för arbetsbelastning

I takt med att programmen växer behöver tjänsterna ofta kommunicera säkert över olika namnområden och miljöer inom samma distribution. Att hantera certifikat och se till att varje tjänst kan verifiera vem den pratar med kan snabbt bli komplex och felbenägen. Azure Kubernetes Application Network eliminerar dessa kostnader genom att automatiskt tilldela och hantera arbetsbelastningsidentiteter.

I en nätverksansluten miljö för program kommunicerar arbetsbelastningar säkert i och mellan namnområden. För att säkerställa att varje tjänst kan vara betrodd och autentiserad tilldelar Application Network varje arbetsbelastning en verifierbar identitet som representerar dess namnområde och tjänstkonto.

Varje Application Network-arbetsbelastning tar automatiskt emot en unik identitet i SPIFFE-format , som innehåller dess namnområde och tjänstkonto. Identiteten formateras på följande sätt:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Den här identiteten är inbäddad i arbetsbelastningscertifikatet och används för att bevisa tjänstens identitet vid kommunikation med andra arbetsbelastningar. Azure Kubernetes Application Network använder den här SPIFFE-baserade identitetsmodellen med Istio-auktoriseringsprinciper så att du kan definiera tydliga och konsekventa regler för vilka tjänster som tillåts kommunicera.

Definiera åtkomstprinciper

Du kan använda Istio AuthorizationPolicies för att styra vilka workloads som tillåts kommunicera inom din miljö. Med de här principerna kan du definiera åtkomst baserat på verifierade arbetsbelastningsidentiteter i stället för nätverksplatser eller IP-adresser. Den här metoden hjälper dig att framtvinga konsekventa åtkomstkontroller även när tjänster skalas och flyttas mellan noder. Du kan till exempel tillåta att endast specifika gatewayer eller belastningar från betrodda namnrymder anropar en tjänst genom att hänvisa till deras SPIFFE-identiteter i principallistan, enligt följande exempel:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Vägledning för principdesign

Tänk på följande metodtips när du utformar auktoriseringsprinciper:

• Ange alltid både namnområde och tjänstkonto för att förhindra oavsiktlig korsnamnrymdsåtkomst.
• Använd principaler för att definiera explicita arbetsbelastningsidentiteter för finfördelad åtkomst.
• Använd namnområden för att definiera bredare förtroendegränser när det är lämpligt.
• Undvik regler som endast matchar tjänstkontonamn utan namnområden, eftersom detta kan ge åtkomst mellan kluster eller miljöer.
• Kombinera AuthorizationPolicies med Kubernetes NetworkPolicies för att framtvinga både identitetsbaserad och nätverksbaserad isolering.

Genom att kombinera azure Kubernetes-programnätverkshanterade identiteter, certifikat och principkontroller kan du implementera identitetsbaserad tjänstkommunikation med lägsta behörighet, säkerställa autentiserad, krypterad och explicit auktoriserad trafik mellan arbetsbelastningar mellan kluster.

Relaterat innehåll

Mer information om Azure Kubernetes Application Network finns i följande artiklar:

• Azure Kubernetes Application Network-arkitektur
• Översikt över azure Kubernetes-programnätverksobservabilitet