Migrera från poddhanterad identitet till arbetsbelastningsidentitet

Artikel
10/24/2023

Den här artikeln fokuserar på att migrera från en poddhanterad identitet till Microsoft Entra Workload ID för ditt AkS-kluster (Azure Kubernetes Service). Det ger också vägledning beroende på vilken version av Azure Identity-klientbiblioteket som används av ditt containerbaserade program.

Om du inte är bekant med Microsoft Entra-arbetsbelastnings-ID kan du läsa följande översiktsartikel .

Innan du börjar

Azure CLI version 2.47.0 eller senare. Kör az --version för att hitta versionen och kör az upgrade för att uppgradera versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.

Migreringsscenarier

I det här avsnittet beskrivs tillgängliga migreringsalternativ beroende på vilken version av Azure Identity SDK som är installerad.

I båda scenariona måste du ha det federerade förtroendet konfigurerat innan du uppdaterar programmet för att använda arbetsbelastningsidentiteten. Följande är de minsta steg som krävs:

Skapa en autentiseringsuppgift för hanterad identitet .
Associera den hanterade identiteten med kubernetes-tjänstkontot som redan används för den poddhanterade identiteten eller skapa ett nytt Kubernetes-tjänstkonto och associera det sedan med den hanterade identiteten.
Upprätta en federerad förtroenderelation mellan den hanterade identiteten och Microsoft Entra-ID:t.

Migrera från den senaste versionen

Om ditt program redan använder den senaste versionen av Azure Identity SDK utför du följande steg för att slutföra autentiseringskonfigurationen:

Distribuera arbetsbelastningsidentitet parallellt med poddhanterad identitet. Du kan starta om programdistributionen för att börja använda arbetsbelastningsidentiteten, där den automatiskt matar in OIDC-anteckningarna i programmet.
När du har verifierat att programmet kan autentiseras kan du ta bort poddhanterade identitetsanteckningar från ditt program och sedan ta bort det poddhanterade identitetstillägget.

Migrera från äldre version

Om ditt program inte använder den senaste versionen av Azure Identity SDK har du två alternativ:

Du kan använda en sidovagn för migrering som vi tillhandahåller i dina Linux-program, som skickar de IMDS-transaktioner som ditt program gör till OpenID Anslut (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. Utför följande steg:
- Distribuera arbetsbelastningen med sidovagn för migrering för att proxyprogram-IMDS-transaktioner.
- Kontrollera att autentiseringstransaktionerna slutförs.
- Schemalägg arbetet för programmen för att uppdatera SDK:erna till en version som stöds.
- När SDK:erna har uppdaterats till den version som stöds kan du ta bort proxy-sidovagnen och distribuera om programmet.
Kommentar

Sidovagnen för migrering stöds inte för produktionsanvändning. Den här funktionen är avsedd att ge dig tid att migrera dina program-SDK:er till en version som stöds och som inte är avsedd eller avsedd att vara en långsiktig lösning. Sidovagnen för migrering är endast tillgänglig för Linux-containrar på grund av att endast tillhandahålla poddhanterade identiteter med Linux-nodpooler.
Skriv om programmet för att stödja den senaste versionen av Azure Identity-klientbiblioteket . Utför följande steg efteråt:
- Starta om programdistributionen för att börja autentisera med hjälp av arbetsbelastningsidentiteten.
- När du har kontrollerat att autentiseringstransaktionerna har slutförts kan du ta bort poddhanterade identitetsanteckningar från ditt program och sedan ta bort det poddhanterade identitetstillägget.

Skapa en hanterad identitet

Om du inte har skapat och tilldelat din podd en hanterad identitet utför du följande steg för att skapa och bevilja nödvändiga behörigheter till lagring, Key Vault eller de resurser som ditt program behöver autentisera med i Azure.

Använd kommandot Azure CLI az account set för att ange en specifik prenumeration som den aktuella aktiva prenumerationen. Använd sedan kommandot az identity create för att skapa en hanterad identitet.

az account set --subscription "subscriptionID"

az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "resourceGroupName" --name "userAssignedIdentityName" --query 'clientId' -otsv)"

Ge den hanterade identiteten de behörigheter som krävs för att få åtkomst till de resurser i Azure som krävs. Information om hur du gör detta finns i Tilldela en hanterad identitet åtkomst till en resurs.
Kör följande kommando för att hämta url:en för OIDC-utfärdaren och spara den i en miljövariabel. Ersätt standardvärdena för klusternamnet och resursgruppens namn.
```
export AKS_OIDC_ISSUER="$(az aks show -n myAKSCluster -g myResourceGroup --query "oidcIssuerProfile.issuerUrl" -otsv)"
```
Variabeln ska innehålla utfärdar-URL:en som liknar följande exempel:
```
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
```
Som standard är utfärdaren inställd på att använda bas-URL:en https://{region}.oic.prod-aks.azure.com/{uuid}, där värdet för {region} matchar platsen där AKS-klustret distribueras. Värdet {uuid} representerar OIDC-nyckeln.

Skapa Kubernetes-tjänstkonto

Om du inte har skapat ett dedikerat Kubernetes-tjänstkonto för det här programmet utför du följande steg för att skapa och kommenterar det sedan med klient-ID:t för den hanterade identiteten som skapades i föregående steg. Använd kommandot az aks get-credentials och ersätt värdena för klusternamnet och resursgruppens namn.

az aks get-credentials -n myAKSCluster -g "${RESOURCE_GROUP}"

Kopiera och klistra in följande indata med flera rader i Azure CLI.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

Följande utdata liknar lyckade skapande av identiteten:

Serviceaccount/workload-identity-sa created

Upprätta federerat förtroende för identitetsautentiseringsuppgifter

Använd kommandot az identity federated-credential create för att skapa den federerade identitetsautentiseringsuppgiften mellan den hanterade identiteten, utfärdaren av tjänstkontot och ämnet. Ersätt värdena resourceGroupName, , userAssignedIdentityNamefederatedIdentityName, serviceAccountNamespaceoch serviceAccountName.

az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange

Kommentar

När autentiseringsuppgifterna för federerade identiteter har lagts till tar det några sekunder innan de sprids. Om en tokenbegäran görs omedelbart efter att den federerade identitetsautentiseringsuppgiften har lagts till kan det leda till fel i ett par minuter eftersom cachen fylls i i katalogen med gamla data. För att undvika det här problemet kan du lägga till en liten fördröjning när du har lagt till den federerade identitetsautentiseringsuppgiften.

Distribuera arbetsbelastningen med sidovagn för migrering

Kommentar

Sidovagnen för migrering stöds inte för produktionsanvändning. Den här funktionen är avsedd att ge dig tid att migrera dina program-SDK:er till en version som stöds och som inte är avsedd eller avsedd att vara en långsiktig lösning. Sidovagnen för migrering är endast för Linux-containrar eftersom poddhanterade identiteter endast var tillgängliga i Linux-nodpooler.

Om ditt program använder hanterad identitet och fortfarande förlitar sig på IMDS för att få en åtkomsttoken kan du använda sidovagnen för arbetsbelastningsidentitetsmigrering för att börja migrera till arbetsbelastningsidentitet. Den här sidovagnen är en migreringslösning och i de långsiktiga programmen bör du ändra deras kod så att de använder de senaste Azure Identity SDK:erna som stöder klientkontroll.

Om du vill uppdatera eller distribuera arbetsbelastningen lägger du bara till dessa poddanteckningar om du vill använda sidovagnen för migrering. Du matar in följande anteckningsvärden för att använda sidovagnen i poddspecifikationen:

azure.workload.identity/inject-proxy-sidecar - värdet är true eller false
azure.workload.identity/proxy-sidecar-port - värdet är önskad port för proxy sidovagnen. Standardvärdet är 8000.

När en podd med ovanstående anteckningar skapas, matar Azure Workload Identity mutating webhook automatiskt in init-containern och proxy-sidovagnen till poddspecifikationen.

Webhooken som redan körs lägger till följande YAML-kodfragment i podddistributionen. Följande är ett exempel på den muterade poddspecifikationen:

apiVersion: v1
kind: Pod
metadata:
  name: httpbin-pod
  labels:
    app: httpbin
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/inject-proxy-sidecar: "true"
spec:
  serviceAccountName: workload-identity-sa
  initContainers:
  - name: init-networking
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy-init:v1.1.0
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: true
      runAsUser: 0
    env:
    - name: PROXY_PORT
      value: "8000"
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  - name: proxy
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v1.1.0
    ports:
    - containerPort: 8000

Den här konfigurationen gäller för alla konfigurationer där en podd skapas. När du har uppdaterat eller distribuerat programmet kan du kontrollera att podden är i ett körningstillstånd med hjälp av kommandot kubectl describe pod . Ersätt värdet podName med avbildningsnamnet för din distribuerade podd.

kubectl describe pods podName

Om du vill kontrollera att podden skickar IMDS-transaktioner använder du kommandot kubectl logs . Ersätt värdet podName med avbildningsnamnet för din distribuerade podd:

kubectl logs podName

Följande loggutdata liknar lyckad kommunikation via proxy-sidovagnen. Kontrollera att loggarna visar att en token har hämtats och att GET-åtgärden lyckas.

I0926 00:29:29.968723       1 proxy.go:97] proxy "msg"="starting the proxy server" "port"=8080 "userAgent"="azure-workload-identity/proxy/v0.13.0-12-gc8527f3 (linux/amd64) c8527f3/2022-09-26-00:19"
I0926 00:29:29.972496       1 proxy.go:173] proxy "msg"="received readyz request" "method"="GET" "uri"="/readyz"
I0926 00:29:30.936769       1 proxy.go:107] proxy "msg"="received token request" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"
I0926 00:29:31.101998       1 proxy.go:129] proxy "msg"="successfully acquired token" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"

Ta bort poddhanterad identitet

När du har slutfört testningen och programmet kan hämta en token med hjälp av proxy-sidovagnen kan du ta bort microsoft Entra-poddhanterad identitetsmappning för podden från klustret och sedan ta bort identiteten.

Kör kommandot az aks pod-identity delete för att ta bort identiteten från podden. Detta bör bara göras när alla poddar i namnområdet med hjälp av den poddhanterade identitetsmappningen har migrerats för att använda sidovagnen.
```
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
```

Nästa steg

Den här artikeln visar hur du konfigurerar din podd för att autentisera med hjälp av en arbetsbelastningsidentitet som ett migreringsalternativ. Mer information om Microsoft Entra-arbetsbelastnings-ID finns i följande översiktsartikel .