Condividi tramite

Eseguire la migrazione dall'identità gestita dal pod all'identità del carico di lavoro

  • Articolo

Questo articolo si focalizza sulla migrazione da un'identità gestita dal pod a un ID del carico di lavoro di Microsoft Entra per il cluster del servizio Azure Kubernetes. Fornisce anche linee guida in base alla versione della libreria client di Azure Identity in uso dall'applicazione basata su contenitori.

Se non si ha familiarità con l'ID del carico di lavoro di Microsoft Entra, vedere l'articolo Panoramica seguente.

Operazioni preliminari

Versione dell'interfaccia della riga di comando di Azure 2.47.0 o successiva. Eseguire az --version per trovare la versione ed eseguire az upgrade per aggiornare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Scenari di migrazione

Questa sezione illustra le opzioni di migrazione disponibili a seconda della versione dell'Azure Identity SDK istallato.

Per ogni scenario è necessario disporre di un trust federato configurato prima di aggiornare l'applicazione per usare l'identità del carico di lavoro. Seguono i passaggi necessari:

Eseguire la migrazione alla versione più recente

Se l'applicazione usa già la versione più recente di Azure Identity SDK, seguire i passaggi seguenti per completare la configurazione dell'autenticazione:

  • Distribuire un'identità gestita in parallelo all'identità gestita dal pod. È possibile riavviare la distribuzione dell'applicazione per iniziare a usare l'identità del carico di lavoro, dove inserisce automaticamente le annotazioni OIDC nell'applicazione.
  • Dopo aver verificato la corretta autenticazione dell'applicazione, è possibile rimuovere le annotazioni dell'identità gestita dal pod dall'applicazione e rimuovere il componente aggiuntivo dell'identità gestita dal pod.

Eseguire la migrazione dalla versione precedente

Se l'applicazione non usa la versione più recente di Azure Identity SDK, sono disponibili due opzioni:

  • È possibile usare un file collaterale di migrazione fornito nell'ambito delle applicazioni Linux, che inoltra i dati delle transazioni IMDS effettuate dall'applicazione tramite OpenID Connect (OIDC). Il file collaterale di migrazione non è progettato per essere una soluzione a lungo termine, ma un modo per iniziare rapidamente a usare l'identità del carico di lavoro. Effettuare le seguenti operazioni per:

    • Distribuire il carico di lavoro con il file collaterale di migrazione per inoltrare i dati delle transazioni IMDS dell'applicazione.
    • Verificare che le transazioni di autenticazione vengano completate correttamente.
    • Pianificare il lavoro affinché vengano aggiornati gli SDK delle applicazioni a una versione supportata.
    • Una volta aggiornati gli SDK a una versione supportata, è possibile rimuovere il file collaterale proxy e distribuire nuovamente l'applicazione.

    Nota

    Il file collaterale di migrazione non è supportato per l'uso in produzione. Questa funzionalità fornisce il tempo necessario per eseguire la migrazione dell'SDK dell'applicazione a una versione supportata e non è una soluzione a lungo termine. Il file collaterale di migrazione è disponibile solo per i contenitori Linux, in quanto fornisce identità gestite dal pod solo con i pool del nodo Linux.

  • Riscrivere l'applicazione per supportare la versione più recente della libreria client di Azure Identity. In seguito, seguire la procedura seguente:

    • Riavviare la distribuzione dell'applicazione per avviare l'autenticazione usando l'identità del carico di lavoro.
    • Una volta verificata la corretta autenticazione dell'applicazione, è possibile rimuovere le annotazioni dell'identità gestita dal pod dall'applicazione e rimuovere il componente aggiuntivo dell'identità gestita dal pod.

Creare un'identità gestita

Se non si dispone di un'identità gestita creata e assegnata al pod, seguire questa procedura per creare e concedere le autorizzazioni necessarie per l'archiviazione, l'insieme di credenziali delle chiavi o qualsiasi risorsa con cui l'applicazione deve eseguire l'autenticazione in Azure.

  1. Usare il comando az account set dell'interfaccia della riga di comando di Azure per impostare una sottoscrizione specifica come sottoscrizione attiva corrente. Quindi, usare il comando az identity create per creare un'identità gestita.

    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)"

  2. Concedere all'identità gestita le autorizzazioni necessarie per accedere alle risorse in Azure necessarie. Per informazioni su come procedere, vedere Assegnare l'accesso a un'identità gestita a una risorsa.

  3. Per ottenere l'URL dell'autorità di certificazione OIDC e salvarlo in una variabile di ambiente, eseguire il comando seguente. Sostituire i valori predefiniti con il nome del cluster e il nome del gruppo di risorse.

    export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"

    La variabile deve contenere l'URL dell'autorità di certificazione simile all'esempio seguente:

    https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/

    Per impostazione predefinita, l'autorità di certificazione è impostata per usare l'URL di base https://{region}.oic.prod-aks.azure.com/{uuid}, dove il valore per {region} corrisponde al luogo dove viene distribuito il cluster del servizio Azure Kubernetes. Il valore {uuid} rappresenta la chiave OIDC.

Creare un account del servizio Kubernetes

Se per questa applicazione non è stato creato un account del servizio Kubernetes dedicato, seguire questa procedura per crearlo e quindi annotarlo con l'ID client dell'identità gestita creata nel passaggio precedente. Usare il comando az aks get-credentials e sostituire i valori del nome del cluster e il nome del gruppo di risorse.

az aks get-credentials --name myAKSCluster --resource-group "${RESOURCE_GROUP}"

Copiare e incollare il seguente input su più righe nell'interfaccia della riga di comando di Azure.

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

L'output seguente è simile alla corretta creazione dell'identità:

Serviceaccount/workload-identity-sa created

Stabilire un trust di credenziali di identità federate

Usare il comando az identity federated-credential create per creare le credenziali di identità federate tra l'identità gestita, l'autorità di certificazione dell'account del servizio e l'oggetto. Sostituire i valori resourceGroupName, userAssignedIdentityName federatedIdentityName, serviceAccountNamespace, e 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

Nota

La propagazione delle credenziali di identità federata dopo l'aggiunta iniziale richiede alcuni secondi. Se una richiesta di token viene creata immediatamente dopo l'aggiunta delle credenziali dell'identità federata, è possibile che si verifichi un errore per un paio di minuti, perché la cache viene popolata nella directory con dati obsoleti. Per evitare questo problema, è possibile aggiungere un lieve ritardo dopo l'aggiunta delle credenziali di identità federate.

Distribuire il carico di lavoro con il file collaterale di migrazione

Nota

Il file collaterale di migrazione non è supportato per l'uso in produzione. Questa funzionalità fornisce il tempo necessario per eseguire la migrazione dell'SDK dell'applicazione a una versione supportata e non è una soluzione a lungo termine. Il file collaterale di migrazione è disponibile solo per i contenitori Linux, in quanto le identità gestite dal pod sono disponibili solo con i pool del nodo Linux.

Se l'applicazione usa l'identità gestita e si basa ancora su IMDS per ottenere un token di accesso, è possibile usare il file collaterale di migrazione dell'identità del carico di lavoro per avviare la migrazione all'identità del carico di lavoro. Questo file collaterale è una soluzione di migrazione e nelle applicazioni a lungo termine è necessario modificare il codice per usare Azure Identity SDK più recenti che supportino l'istruzione client.

Per aggiornare o distribuire il carico di lavoro, aggiungere queste annotazioni pod solo se si vuole usare il file collaterale di migrazione. Inserire i valori di annotazione seguenti per usare il file collaterale nella specifica del pod:

  • azure.workload.identity/inject-proxy-sidecar: il valore è true o false
  • azure.workload.identity/proxy-sidecar-port: il valore è la porta desiderata per il file collaterale proxy. Il valore predefinito è 8000.

Quando viene creato un pod con le annotazioni precedenti, il webhook di modifica dell'identità del carico di lavoro di Azure inserisce automaticamente init-container e il file collaterale proxy nella specifica del pod.

Il webhook già in esecuzione aggiunge i frammenti YAML seguenti alla distribuzione dei pod. Di seguito è riportato un esempio della specifica del pod mutata:

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

Questa configurazione si applica a qualsiasi configurazione in cui viene creato un pod. Dopo l'aggiornamento o la distribuzione dell'applicazione, è possibile verificare che il pod sia in esecuzione usando il comando kubectl describe pod. Sostituire il valore podName con il nome dell'immagine del pod distribuito.

kubectl describe pods podName

Per verificare che il pod passi transazioni IMDS, usare il comando kubectl logs. Sostituire il valore podName con il nome dell'immagine del pod distribuito:

kubectl logs podName

L'output del log seguente è simile alla corretta comunicazione tramite il file collaterale proxy. Verificare che i log mostrino che sia stato acquisito correttamente un token e che l'operazione GET abbia esito positivo.

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>"

Rimuovere l'identità gestita dal pod

Dopo aver completato il test e l'applicazione è in grado di ottenere un token usando il file collaterale proxy, è possibile rimuovere il mapping dell'identità gestita dal pod di Microsoft Entra per il pod dal cluster e quindi rimuovere l'identità.

  1. Eseguire il comando az aks pod-identity delete per rimuovere l'identità dal pod. Questa operazione deve essere eseguita solo una volta eseguita la migrazione di tutti i pod nello spazio dei nomi usando il mapping delle identità gestite dal pod per usare il file collaterale.

    az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster

Passaggi successivi

Questo articolo illustra come configurare il pod per l'autenticazione usando un'identità del carico di lavoro come opzione di migrazione. Per altre informazioni sull'ID del carico di lavoro di Microsoft Entra, vedere l'articolo Panoramica seguente.