AKS Workload Identity: Autentisera poddar mot Azure AI-tjänster utan hemligheter

Varför Workload Identity på AKS

Det gamla sättet att hantera Azure-autentisering på pod-nivå var AAD Pod Identity. Det förlitade sig på CRDs, NMI-daemonsets som kördes på varje nod och en hel del YAML-konfiguration. Det fungerade, men det var komplext att drifta och hade kända säkerhetsbegränsningar. Microsoft har ersatt det med en renare modell.

AKS Workload Identity (GA sedan maj 2023) ersätter allt detta med Kubernetes service account token federation mot Entra ID. Inga daemonsets, inga CRDs, inga NMI-poddar som fångar upp trafik. Din pod får en Entra ID-token som projiceras av Kubernetes, och Azure accepterar den direkt. Resultatet är en enklare arkitektur med en bättre säkerhetsmodell.

Hur det fungerar

Tre delar kopplas samman:

• En Kubernetes service account med en annotation som pekar på den hanterade identitetens client ID
• En user-assigned managed identity i Azure med en federated credential som litar på just den service account:en
• RBAC-rolltilldelningar på Azure-målresurserna (i det här fallet Azure OpenAI)

När en pod körs med den service account:en projicerar Kubernetes en signerad token in i podden. Azure Identity SDK byter den mot en Entra ID-åtkomsttoken via den federerade förtroendekedjan. DefaultAzureCredential hanterar detta automatiskt, så din applikationskod behöver ingen speciell hantering.

Terraform: AKS-kluster med Workload Identity

De två nyckelinställningarna på AKS-klustret är oidc_issuer_enabled och workload_identity_enabled. OIDC-utfärdaren exponerar en discovery-endpoint som Azure använder för att validera tokens från klustret.

Terraform: Managed Identity och Federated Credential

Skapa sedan en user-assigned managed identity, en federated credential som kopplar den till Kubernetes service account:en, och en rolltilldelning som ger åtkomst till Azure OpenAI.

Fältet subject följer formatet system:serviceaccount:<namespace>:<service-account-name>. Det är så Azure vet vilken Kubernetes service account som får begära tokens för den här hanterade identiteten.

Kubernetes: Service Account och Pod

På Kubernetes-sidan behöver service account:en två saker: en annotation med den hanterade identitetens client ID och en label som talar om för webhooken att injicera den projicerade token-volymen.

Notera att det inte finns några hemligheter, inga key vaults och inga API-nycklar någonstans i deploymenten. Workload identity-webhooken monterar automatiskt den projicerade service account-token och sätter de miljövariabler som Azure Identity SDK behöver.

Applikationskod: Python med DefaultAzureCredential

Applikationskoden är enkel. DefaultAzureCredential upptäcker automatiskt workload identity-miljön och hämtar en token för Azure Cognitive Services.

Samma kod fungerar utan ändringar i lokal utveckling (där DefaultAzureCredential faller tillbaka på Azure CLI eller VS Code-autentisering) och i produktion på AKS (där den plockar upp den projicerade token). Inga kodändringar behövs mellan miljöer.

Verifiera konfigurationen

Efter deploy, verifiera att alla delar är korrekt kopplade.

Om OIDC-utfärdarens URL är tom är workload identity inte aktiverat på klustret. Om listan med federerade autentiseringsuppgifter är tom har förtroendeförhållandet inte etablerats. Kontrollera poddloggarna efter autentiseringsfel; Azure Identity SDK ger tydliga felmeddelanden när token-utbytet misslyckas.

Vidare läsning

AKS Workload Identity overview beskriver arkitekturen och scenarierna som stöds i detalj. Deploy and configure workload identity on an AKS cluster går igenom Azure CLI-arbetsflödet om du föredrar det framför Terraform.