Använda Microsoft Entra-arbetsbelastnings-ID med Azure Kubernetes Service (AKS)
Arbetsbelastningar som distribueras i ett AKS-kluster (Azure Kubernetes Services) kräver microsoft Entra-programautentiseringsuppgifter eller hanterade identiteter för åtkomst till Microsoft Entra-skyddade resurser, till exempel Azure Key Vault och Microsoft Graph. Microsoft Entra Workload ID integreras med funktionerna som är inbyggda i Kubernetes för att federera med externa identitetsprovidrar.
Microsoft Entra-arbetsbelastnings-ID använder volymprojektion för tjänstkontotoken (dvs. ett tjänstkonto) för att göra det möjligt för poddar att använda en Kubernetes-identitet. En Kubernetes-token utfärdas och OIDC-federation gör det möjligt för Kubernetes-program att komma åt Azure-resurser på ett säkert sätt med Microsoft Entra-ID, baserat på kommenterade tjänstkonton.
Microsoft Entra-arbetsbelastnings-ID fungerar särskilt bra med Azure Identity-klientbiblioteken eller MSAL-samlingen (Microsoft Authentication Library ) tillsammans med programregistrering. Din arbetsbelastning kan använda något av dessa bibliotek för att smidigt autentisera och komma åt Azure-molnresurser.
Den här artikeln hjälper dig att förstå Microsoft Entra-arbetsbelastnings-ID och granskar de alternativ som är tillgängliga för att planera din projektstrategi och potentiella migrering från Microsoft Entra poddhanterad identitet.
Kommentar
Du kan använda Service Connector för att konfigurera vissa steg automatiskt. Se även: Vad är Service Connector?
Beroenden
- AKS stöder Microsoft Entra-arbetsbelastnings-ID på version 1.22 och senare.
- Azure CLI version 2.47.0 eller senare. Kör
az --version
för att hitta versionen och köraz upgrade
för att uppgradera versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.
Azure Identity-klientbibliotek
I Azure Identity-klientbiblioteken väljer du någon av följande metoder:
- Använd
DefaultAzureCredential
, som försöker användaWorkloadIdentityCredential
. - Skapa en
ChainedTokenCredential
instans som innehållerWorkloadIdentityCredential
. - Använd
WorkloadIdentityCredential
direkt.
Följande tabell innehåller den lägsta paketversion som krävs för varje språkekosystems klientbibliotek.
Ekosystem | Bibliotek | Minimiversion |
---|---|---|
.NET | Azure.Identity | 1.9.0 |
C++ | azure-identity-cpp | 1.6.0 |
Go | azidentity | 1.3.0 |
Java | azure-identity | 1.9.0 |
Node.js | @azure/identitet | 3.2.0 |
Python | azure-identity | 1.13.0 |
I följande kodexempel DefaultAzureCredential
används. Den här typen av autentiseringsuppgifter använder miljövariablerna som matas in av Azure Workload Identity som muterar webhooken för att autentisera med Azure Key Vault.
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
string keyVaultUrl = Environment.GetEnvironmentVariable("KEYVAULT_URL");
string secretName = Environment.GetEnvironmentVariable("SECRET_NAME");
var client = new SecretClient(
new Uri(keyVaultUrl),
new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync(secretName);
Microsoft Authentication Library (MSAL)
Följande klientbibliotek är den lägsta version som krävs.
Ekosystem | Bibliotek | Bild | Exempel | Har Windows |
---|---|---|---|---|
.NET | Microsoft Authentication Library-for-dotnet | ghcr.io/azure/azure-workload-identity/msal-net:latest |
Länk | Ja |
Go | Microsoft Authentication Library-for-go | ghcr.io/azure/azure-workload-identity/msal-go:latest |
Länk | Ja |
Java | Microsoft Authentication Library-for-java | ghcr.io/azure/azure-workload-identity/msal-java:latest |
Länk | Nej |
JavaScript | Microsoft Authentication Library-for-js | ghcr.io/azure/azure-workload-identity/msal-node:latest |
Länk | Nej |
Python | Microsoft Authentication Library-for-python | ghcr.io/azure/azure-workload-identity/msal-python:latest |
Länk | Nej |
Begränsningar
- Du kan ha högst 20 federerade identitetsuppgifter per hanterad identitet.
- När autentiseringsuppgifterna för federerade identiteter har lagts till tar det några sekunder innan de sprids.
- De virtuella noderna som läggs till, baserat på öppen källkod projektet Virtual Kubelet, stöds inte.
- Skapande av federerade identitetsuppgifter stöds inte för användartilldelade hanterade identiteter i dessa regioner.
Hur det fungerar
I den här säkerhetsmodellen fungerar AKS-klustret som tokenutfärdare. Microsoft Entra ID använder OpenID Connect för att identifiera offentliga signeringsnycklar och verifiera autenticiteten för tjänstkontotoken innan du utbyter den mot en Microsoft Entra-token. Din arbetsbelastning kan byta ut en tjänstkontotoken som projiceras till dess volym mot en Microsoft Entra-token med hjälp av Azure Identity-klientbiblioteket eller Microsoft Authentication Library (MSAL).
I följande tabell beskrivs de nödvändiga OIDC-utfärdarslutpunkterna för Microsoft Entra-arbetsbelastnings-ID:
Slutpunkt | beskrivning |
---|---|
{IssuerURL}/.well-known/openid-configuration |
Kallas även för OIDC-identifieringsdokumentet. Detta innehåller metadata om utfärdarens konfigurationer. |
{IssuerURL}/openid/v1/jwks |
Detta innehåller de offentliga signeringsnycklar som Microsoft Entra-ID använder för att verifiera autenticiteten för tjänstkontotoken. |
Följande diagram sammanfattar autentiseringssekvensen med OpenID Connect.
Automatisk rotation av Webhook-certifikat
På samma sätt som andra webhook-tillägg roteras certifikatet av automatisk rotationsåtgärd för klustercertifikat.
Tjänstkontoetiketter och anteckningar
Microsoft Entra-arbetsbelastnings-ID stöder följande mappningar relaterade till ett tjänstkonto:
- En-till-en, där ett tjänstkonto refererar till ett Microsoft Entra-objekt.
- Många-till-en, där flera tjänstkonton refererar till samma Microsoft Entra-objekt.
- En-till-många, där ett tjänstkonto refererar till flera Microsoft Entra-objekt genom att ändra klient-ID-anteckningen. Mer information finns i Så här federerar du flera identiteter med ett Kubernetes-tjänstkonto.
Kommentar
Om anteckningarna för tjänstkontot uppdateras måste du starta om podden för att ändringarna ska börja gälla.
Om du har använt Microsoft Entra-poddhanterad identitet bör du tänka på ett tjänstkonto som ett Azure-säkerhetsobjekt, förutom att ett tjänstkonto är en del av kubernetes-kärn-API:et i stället för en anpassad resursdefinition (CRD). I följande avsnitt beskrivs en lista över tillgängliga etiketter och anteckningar som kan användas för att konfigurera beteendet vid utbyte av tjänstkontotoken för en Microsoft Entra-åtkomsttoken.
Anteckningar för tjänstkonto
Alla anteckningar är valfria. Om anteckningen inte har angetts används standardvärdet.
Anteckning | beskrivning | Standard |
---|---|---|
azure.workload.identity/client-id |
Representerar Microsoft Entra-programmet klient-ID som ska användas med podden. |
|
azure.workload.identity/tenant-id |
Representerar Azure-klientorganisations-ID:t där Microsoft Entra-programmet är registrerat. |
AZURE_TENANT_ID miljövariabeln extraherad från azure-wi-webhook-config ConfigMap. |
azure.workload.identity/service-account-token-expiration |
Representerar fältet expirationSeconds förprojekterad tjänstkontotoken. Det är ett valfritt fält som du konfigurerar för att förhindra stilleståndstid orsakas av fel under uppdatering av tjänstkontotoken. Förfallodatum för Kubernetes-tjänstkontotoken korreleras inte med Microsoft Entra-token. Microsoft Entra-token upphör att gälla om 24 timmar efter att de har utfärdats. |
3600 Intervallet som stöds är 3600-86400. |
Poddetiketter
Kommentar
För program som använder arbetsbelastningsidentitet måste du lägga till etiketten azure.workload.identity/use: "true"
i poddspecifikationen för AKS för att flytta arbetsbelastningsidentiteten till ett felstängningsscenario för att tillhandahålla ett konsekvent och tillförlitligt beteende för poddar som behöver använda arbetsbelastningsidentitet. Annars misslyckas poddarna när de har startats om.
Etikett | Description | Rekommenderat värde | Obligatoriskt |
---|---|---|---|
azure.workload.identity/use |
Den här etiketten krävs i poddmallsspecifikationen. Endast poddar med den här etiketten muteras av den azure-workload-identity som muterar webhooken för antagning för att mata in azure-specifika miljövariabler och den beräknade volymen för tjänstkontotoken. | true | Ja |
Poddanteckningar
Alla anteckningar är valfria. Om anteckningen inte har angetts används standardvärdet.
Anteckning | beskrivning | Standard |
---|---|---|
azure.workload.identity/service-account-token-expiration |
Representerar fältet expirationSeconds för den beräknade tjänstkontotoken. Det är ett valfritt fält som du konfigurerar för att förhindra avbrott som orsakas av fel vid uppdatering av tjänstkontotoken. Förfallodatum för Kubernetes-tjänstkontotoken korreleras inte med Microsoft Entra-token. Microsoft Entra-token upphör att gälla om 24 timmar efter att de har utfärdats. 1 |
3600 Intervallet som stöds är 3600-86400. |
azure.workload.identity/skip-containers |
Representerar en semikolonavgränsad lista över containrar för att hoppa över att lägga till den beräknade tokenvolymen för tjänstkontot. Exempel: container1;container2 |
Som standard läggs den beräknade tokenvolymen för tjänstkontot till i alla containrar om tjänstkontot är märkt med azure.workload.identity/use: true . |
azure.workload.identity/inject-proxy-sidecar |
Matar in en proxyinit-container och proxy-sidovagn i podden. Proxy-sidovagnen används för att fånga upp tokenbegäranden till IMDS och hämta en Microsoft Entra-token åt användaren med federerade identitetsautentiseringsuppgifter. | true |
azure.workload.identity/proxy-sidecar-port |
Representerar porten för proxy-sidovagnen. | 8000 |
1 Har företräde om tjänstkontot också kommenteras.
Migrera till Microsoft Entra-arbetsbelastnings-ID
I ett kluster som redan kör en poddhanterad identitet kan du konfigurera den så att den använder arbetsbelastningsidentitet på ett av två sätt. Med det första alternativet kan du använda samma konfiguration som du har implementerat för poddhanterad identitet. Du kan kommentera tjänstkontot i namnområdet med identiteten för att aktivera Microsoft Entra-arbetsbelastnings-ID och mata in anteckningarna i poddarna.
Det andra alternativet är att skriva om programmet så att det använder den senaste versionen av Azure Identity-klientbiblioteket.
För att effektivisera och underlätta migreringsprocessen har vi utvecklat en sidovagn för migrering som konverterar de IMDS-transaktioner som ditt program gör till OpenID Connect (OIDC). Sidovagnen för migrering är inte avsedd att vara en långsiktig lösning, utan ett sätt att snabbt komma igång med arbetsbelastningsidentiteten. Om du kör sidovagnen för migrering i programmet skickas imds-transaktionerna över till OIDC. Den alternativa metoden är att uppgradera till en version som stöds av Azure Identity-klientbiblioteket , som stöder OIDC-autentisering.
I följande tabell sammanfattas våra migrerings- eller distributionsrekommendationer för arbetsbelastningsidentitet.
Scenario | beskrivning |
---|---|
Ny eller befintlig klusterdistribution kör en version av Azure Identity-klientbiblioteket som stöds | Inga migreringssteg krävs. Exempel på distributionsresurser: Distribuera och konfigurera arbetsbelastningsidentitet i ett nytt kluster |
Ny eller befintlig klusterdistribution kör en version av Azure Identity-klientbiblioteket som inte stöds | Uppdatera containeravbildningen så att den använder en version av Azure Identity SDK som stöds, eller använd sidovagnen för migrering. |
Nästa steg
- Information om hur du konfigurerar podden för att autentisera med hjälp av en arbetsbelastningsidentitet som migreringsalternativ finns i Modernisera programautentisering med arbetsbelastningsidentitet.
- Se Distribuera och konfigurera ett AKS-kluster med arbetsbelastningsidentitet, som hjälper dig att distribuera ett Azure Kubernetes Service-kluster och konfigurera ett exempelprogram för att använda en arbetsbelastningsidentitet.
Azure Kubernetes Service