Effectuer une migration de l’identité managée du pod vers l’identité de charge de travail

Article
08/02/2024

Cet article est axé sur la migration à partir d’une identité managée par un pod vers une identité Microsoft Entra Workload ID pour votre cluster Azure Kubernetes Service (AKS). Il fournit également des conseils en fonction de la version de la bibliothèque de client Azure Identity utilisée par votre application basée sur un conteneur.

Si vous ne connaissez pas le concept Microsoft Entra Workload ID, consultez l’article Vue d’ensemble suivant.

Avant de commencer

Azure CLI version 2.47.0 ou ultérieure. Exécutez az --version pour rechercher la version, puis exécutez az upgrade pour mettre à niveau la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Scénarios de migration

Cette section explique les options de migration disponibles en fonction de la version du Kit de développement logiciel (SDK) Azure Identity installé.

Pour l’un ou l’autre scénario, vous devez configurer l’approbation fédérée avant de mettre à jour votre application pour qu’elle utilise l’identité de charge de travail. Voici les étapes minimales requises :

Créez les informations d’identification de l’identité managée.
Associez l’identité managée au compte de service Kubernetes déjà utilisé pour l’identité managée par pod, ou créez un nouveau compte de service Kubernetes puis associez-le à l’identité managée.
Établissez une relation d’approbation fédérée entre l’identité managée et Microsoft Entra ID.

Migrer à partir de la dernière version

Si votre application utilise déjà la dernière version du Kit de développement logiciel (SDK) Azure Identity, effectuez les étapes suivantes pour terminer la configuration de l’authentification :

Déployez l’identité de charge de travail en parallèle avec l’identité managée par pod. Vous pouvez redémarrer votre déploiement d’application pour commencer à utiliser l’identité de charge de travail ; il injecte automatiquement les annotations OIDC dans l’application.
Après avoir vérifié que l’application est en mesure de s’authentifier correctement, vous pouvez supprimer les annotations d’identité managée par pod de votre application, puis supprimer le module complémentaire d’identité managée par pod.

Migrer à partir d’une version antérieure

Si votre application n’utilise pas la dernière version du Kit de développement logiciel (SDK) Azure Identity, vous avez deux options :

Vous pouvez utiliser un side-car de migration que nous fournissons au sein de vos applications Linux. Celui-ci redirige par proxy les transactions IMDS effectuées par votre application vers OpenID Connect (OIDC). Le sidecar de migration n’est pas destiné à être une solution à long terme, mais un moyen d’être rapidement opérationnel pour l’identité de charge de travail. Effectuez les étapes suivantes pour :
- Déployer la charge de travail avec side-car de migration afin de proxyser les transactions IMDS de l’application.
- Vérifiez que les transactions d’authentification se terminent correctement.
- Planifiez le travail pour que les applications mettent à jour leurs kits de développement logiciel (SDK) vers une version prise en charge.
- Une fois les kits de développement logiciel (SDK) mis à jour vers la version prise en charge, vous pouvez supprimer le side-car proxy et redéployer l’application.
Notes

Le side-car de migration n’est pas pris en charge pour l’utilisation en production. Cette fonctionnalité est destinée à vous donner du temps pour effectuer la migration de vos SDK d’application vers une version prise en charge. Il ne s’agit pas d’une solution à long terme. Le side-car de migration est uniquement disponible pour les conteneurs Linux, en raison de la fourniture unique d’identités gérées par pod avec des pools de nœuds Linux.
Réécrire votre application afin qu’elle prenne en charge la dernière version de la bibliothèque de client Azure Identity. Ensuite, effectuez les étapes suivantes :
- Redémarrez le déploiement de votre application pour commencer l’authentification à l’aide de l’identité de charge de travail.
- Après avoir vérifié que les transactions d’authentification se terminent correctement, vous pouvez supprimer les annotations d’identité managées par pod de votre application, puis supprimer le module complémentaire d’identité managée par pod.

Créer une identité managée

Si vous n’avez pas d’identité managée créée et affectée à votre pod, procédez comme suit pour créer et accorder les autorisations nécessaires au stockage, à Key Vault ou toutes autres ressources dont votre application a besoin pour s’authentifier auprès d’Azure.

Utilisez la commande Azure CLI az account set pour définir un abonnement spécifique comme abonnement actif actuel. Utilisez ensuite la commande az identity create pour créer une identité managée.

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

Accordez à l’identité managée les autorisations requises pour accéder aux ressources dans Azure. Si vous souhaitez en savoir plus sur la procédure à suivre, veuillez consulter la rubrique Attribuer à une identité managée l’accès à une ressource.
Pour obtenir l’URL de l’émetteur OIDC et l’enregistrer dans une variable d’environnement, exécutez la commande suivante. Remplacez les valeurs par défaut pour le nom du cluster et le nom du groupe de ressources.
```
export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
```
La variable doit contenir l’URL de l’émetteur, comme dans l’exemple suivant :
```
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
```
L’émetteur est défini par défaut pour utiliser l’URL de base https://{region}.oic.prod-aks.azure.com/{uuid}, avec la valeur de {region} qui correspond à l’emplacement de déploiement du cluster AKS. La valeur {uuid} représente la clé OIDC.

Créer un compte de service Kubernetes

Si vous n’avez pas de compte de service Kubernetes dédié créé pour cette application, procédez comme suit pour le créer, puis annotez-le avec l’ID client de l’identité managée créée à l’étape précédente. Utilisez la commande az aks get-credentials et remplacez les valeurs pour le nom du cluster et le nom du groupe de ressources.

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

Copiez et collez l’entrée multiligne suivante dans 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

La sortie suivante ressemble à la création réussie de l’identité :

Serviceaccount/workload-identity-sa created

Établir l’approbation des informations d’identification d’identité fédérée

Utilisez la commande az identity federated-credential create pour créer les informations d’identification d’identité fédérées entre l’identité managée, l’émetteur du compte de service et le sujet. Remplacez les valeurs resourceGroupName, userAssignedIdentityName, federatedIdentityName, serviceAccountNamespace et 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

Notes

Il faut quelques secondes pour que les informations d’identification d’identité fédérée soient propagées après avoir été ajoutées initialement. Si une requête de jeton est effectuée immédiatement après l’ajout des informations d’identification d’identité fédérée, cela peut entraîner un échec pendant quelques minutes, car le cache est rempli dans le répertoire avec d’anciennes données. Pour éviter ce problème, vous pouvez ajouter un léger délai après l’ajout des informations d’identification d’identité fédérée.

Déployer la charge de travail avec side-car de migration

Notes

Le side-car de migration n’est pas pris en charge pour l’utilisation en production. Cette fonctionnalité est destinée à vous donner du temps pour effectuer la migration de vos SDK d’application vers une version prise en charge. Il ne s’agit pas d’une solution à long terme. Le side-car de la migration n’est destiné qu’aux conteneurs Linux, car les identités managées par pod n’étaient disponibles que sur les pools de nœuds Linux.

Si votre application utilise une identité managée et s’appuie toujours sur IMDS pour obtenir un jeton d’accès, vous pouvez utiliser le sidecar de migration d’identité de charge de travail pour commencer à migrer vers l’identité de charge de travail. Ce sidecar est une solution de migration, et dans les applications à long terme, vous devez modifier le code pour utiliser les derniers SDK Azure Identity qui prennent en charge l’assertion du client.

Pour mettre à jour ou déployer la charge de travail, ajoutez ces annotations de pod uniquement si vous souhaitez utiliser le sidecar de migration. Vous devez injecter les valeurs d’annotation suivantes pour utiliser le sidecar dans votre spécification de pod :

azure.workload.identity/inject-proxy-sidecar - la valeur est true ou false
azure.workload.identity/proxy-sidecar-port - le port souhaité pour le sidecar de proxy. La valeur par défaut est 8000.

Lorsqu’un pod avec les annotations ci-dessus est créé, l’identité de charge de travail Azure mutant le webhook injecte automatiquement le sidecar init-container et de proxy dans la spécification du pod.

Le webhook qui est déjà en cours d’exécution ajoute les extraits de code YAML suivants au déploiement du pod. Voici un exemple de spécification de pod muté :

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

Cette configuration s’applique à toute configuration où un pod est créé. Après avoir mis à jour ou déployé votre application, vous pouvez vérifier que le pod est en état de fonctionnement à l’aide de la commande kubectl describe pod. Remplacez la valeur podName par le nom de l’image de votre pod déployé.

kubectl describe pods podName

Pour vérifier que le pod transmet des transactions IMDS, utilisez la commande kubectl logs. Remplacez la valeur podName par le nom de l’image de votre pod déployé :

kubectl logs podName

La sortie de journal suivante ressemble à une communication réussie via le sidecar de proxy. Vérifiez que les journaux indiquent qu’un jeton a bien été acquis et que l’opération GET a abouti.

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

Supprimer l’identité managée par pod

Une fois que vous avez effectué vos tests et que l’application est en mesure d’obtenir un jeton en utilisant le side-car de proxy, vous pouvez supprimer le mappage d’identité managée par un pod Microsoft Entra pour le pod de votre cluster, puis supprimer l’identité.

Exécutez la commande az aks pod-identity delete pour supprimer l’identité de votre pod. Cette opération doit être effectuée uniquement après que tous les pods de l’espace de noms utilisant le mappage d’identité géré par pod ont migré pour utiliser le sidecar.
```
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
```

Étapes suivantes

Cet article vous a montré comment configurer votre pod pour vous authentifier à l’aide d’une identité de charge de travail comme option de migration. Pour obtenir plus d’informations sur Microsoft Entra Workload ID, consultez la Vue d’ensemble suivante.

Partager via