Déployer et configurer une identité de charge de travail dans un cluster Azure Kubernetes Service (AKS)

AKS (Azure Kubernetes Service) est un service Kubernetes managé qui vous permet de déployer et de gérer rapidement des clusters Kubernetes. En lisant cet article, vous pourrez :

  • Déployer un cluster AKS à l’aide d’Azure CLI, qui inclut l’émetteur OpenID Connect et une identité Microsoft Entra Workload ID
  • Accorder l’accès à votre Azure Key Vault
  • Créer Microsoft Entra Workload ID et un compte de service Kubernetes
  • Configurez l’identité managée pour la fédération de jeton.

Cet article part du principe que vous avez une compréhension de base des concepts de Kubernetes. Pour plus d’informations, consultez Concepts de base de Kubernetes pour AKS (Azure Kubernetes Service). Si vous ne connaissez pas le concept Microsoft Entra Workload ID, consultez l’article Vue d’ensemble suivant.

  • Cet article nécessite la version 2.47.0 ou ultérieure de Azure CLI. Si vous utilisez Azure Cloud Shell, la version la plus récente est déjà installée.

  • L’identité que vous utilisez pour créer votre cluster dispose des autorisations minimales appropriées. Pour plus d’informations concernant l’accès et l’identité pour AKS, consultez Options d’accès et d’identité pour Kubernetes Azure Service (AKS).

  • Si vous avez plusieurs abonnements Azure, sélectionnez l’ID d’abonnement approprié dans lequel les ressources doivent être facturées avec la commande az account.

Remarque

Au lieu de configurer manuellement toutes les étapes, il existe une autre implémentation appelée Service Connector qui vous aidera à configurer automatiquement certaines étapes et à obtenir le même résultat. Consultez également : Tutoriel : Se connecter à un compte Stockage Azure dans Azure Kubernetes Service (AKS) avec le Connecteur de services à l’aide de l’identité de charge de travail.

Exporter des variables d’environnement

Pour simplifier les étapes de configuration de l’identité requise, les étapes ci-dessous définissent des variables d’environnement pour les références sur le cluster.

Exécutez les commandes suivantes pour créer ces variables. Remplacez les valeurs par défaut pour RESOURCE_GROUP, LOCATION, SERVICE_ACCOUNT_NAME, SUBSCRIPTION, USER_ASSIGNED_IDENTITY_NAME et FEDERATED_IDENTITY_CREDENTIAL_NAME.

export RESOURCE_GROUP="myResourceGroup"
export LOCATION="westcentralus"
export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"

Créer un cluster AKS

Créez un cluster AKS à l’aide de la commande az aks create avec le paramètre --enable-oidc-issuer pour utiliser l’émetteur OIDC. L’exemple suivant crée un cluster à un nœud nommé myAKSCluster avec un nœud dans myResourceGroup :

az aks create -g "${RESOURCE_GROUP}" -n myAKSCluster --enable-oidc-issuer --enable-workload-identity --generate-ssh-keys

Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.

Notes

Lors de la création d’un cluster AKS, un deuxième groupe de ressources est automatiquement créé pour stocker les ressources AKS. Pour plus d’informations, consultez Pourquoi deux groupes de ressources sont-ils créés avec AKS ?.

Mettre à jour un cluster AKS existant

Vous pouvez mettre à jour un cluster AKS à l’aide de la commande az aks update avec le --enable-oidc-issuer paramètre --enable-workload-identity pour utiliser l’émetteur OIDC. L’exemple suivant démarre un cluster nommé myAKSCluster :

az aks update -g "${RESOURCE_GROUP}" -n myAKSCluster --enable-oidc-issuer --enable-workload-identity

Obtenir l’URL de l’émetteur OIDC

Pour obtenir l’URL de l’émetteur OIDC et l’enregistrer dans une variable d’environnement, exécutez la commande suivante. Remplacez la valeur par défaut des arguments -n, qui est le nom du cluster :

export AKS_OIDC_ISSUER="$(az aks show -n myAKSCluster -g "${RESOURCE_GROUP}" --query "oidcIssuerProfile.issuerUrl" -o tsv)"

La variable doit contenir l’URL de l’émetteur, comme décrit dans l’exemple suivant :

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

L’émetteur est défini par défaut pour utiliser l’URL de base https://{region}.oic.prod-aks.azure.com/{tenant_id}/{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 une identité managée

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 identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

Nous créons ensuite une variable pour l’ID d’identité managée.

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o tsv)"

Créer un compte de service Kubernetes

Créez un compte de service Kubernetes et 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 -n myAKSCluster -g "${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 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.

az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --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 votre application

Lorsque vous déployez vos pods d’application, le manifeste doit référencer le compte de service créé lors de l’étape Créer un compte de service Kubernetes. Le manifeste suivant montre comment référencer le compte, en particulier les propriétés metadata\namespace et spec\serviceAccountName :

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: your-pod
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
  labels:
    azure.workload.identity/use: "true"  # Required, only the pods with this label can use workload identity
spec:
  serviceAccountName: "${SERVICE_ACCOUNT_NAME}"
  containers:
    - image: <your image>
      name: <containerName>
EOF

Important

Vérifiez que vos pods d’application qui utilisent l’identité de charge de travail ont ajouté l’étiquette suivante azure.workload.identity/use: "true" à votre spec de pod, sinon les pods échouent après le redémarrage.

Facultatif : octroyer des autorisations pour accéder à Azure Key Vault

Cette étape est nécessaire si vous devez accéder à des secrets, clés et certificats montés dans Azure Key Vault à partir d’un pod. Procédez comme suit pour configurer l’accès avec une identité managée. Ces étapes supposent que vous disposez d’un Azure Key Vault déjà créé et configuré dans votre abonnement. Si vous n’en avez pas, consultez Créer un Azure Key Vault à l’aide d’Azure CLI.

Avant de continuer, vous avez besoin des informations suivantes :

  • Nom du Key Vault
  • Groupe de ressources contenant le Key Vault

Vous pouvez récupérer ces informations à l’aide de la commande Azure CLI az keyvault list.

  1. Définissez une stratégie d’accès pour permettre à l’identité managée d’accéder aux secrets de votre Key Vault en exécutant les commandes suivantes :

    export KEYVAULT_RESOURCE_GROUP="myResourceGroup"
    export KEYVAULT_NAME="myKeyVault"
    export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o tsv)"
    
    az keyvault set-policy --name "${KEYVAULT_NAME}" --secret-permissions get --spn "${USER_ASSIGNED_CLIENT_ID}"
    
  2. Créez un secret dans Key Vault :

    export KEYVAULT_SECRET_NAME="my-secret"
    
    az keyvault secret set --vault-name "${KEYVAULT_NAME}" \
       --name "${KEYVAULT_SECRET_NAME}" \
       --value "Hello\!"
    
  3. Exportez l’URL de Key Vault :

    export KEYVAULT_URL="$(az keyvault show -g ${KEYVAULT_RESOURCE_GROUP} -n ${KEYVAULT_NAME} --query properties.vaultUri -o tsv)"
    
  4. Déployez un pod qui référence le compte de service et l’URL de Key Vault ci-dessus :

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: quick-start
      namespace: ${SERVICE_ACCOUNT_NAMESPACE}
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: ${SERVICE_ACCOUNT_NAME}
      containers:
        - image: ghcr.io/azure/azure-workload-identity/msal-go
          name: oidc
          env:
          - name: KEYVAULT_URL
            value: ${KEYVAULT_URL}
          - name: SECRET_NAME
            value: ${KEYVAULT_SECRET_NAME}
      nodeSelector:
        kubernetes.io/os: linux
    EOF
    

Pour vérifier si toutes les propriétés sont injectées correctement par le webhook, utilisez la commande kubectl describe :

kubectl describe pod quick-start | grep "SECRET_NAME:"

Si l’opération réussit, la sortie doit ressembler à la suivante :

      SECRET_NAME:                 ${KEYVAULT_SECRET_NAME}

Pour s’assurer que le pod est capable d’obtenir un jeton et d’accéder à la ressource, utilisez la commande kubectl logs :

kubectl logs quick-start

Si l’opération réussit, la sortie doit ressembler à la suivante :

I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello\\!"

Désactiver l’identité de charge de travail

Pour désactiver Microsoft Entra Workload ID sur le cluster AKS où elle a été activée et configurée, vous pouvez exécuter la commande suivante :

az aks update --resource-group "${RESOURCE_GROUP}" --name myAKSCluster --disable-workload-identity

Étapes suivantes

Dans cet article, vous avez déployé un cluster Kubernetes et l’avez configuré pour utiliser une identité de charge de travail en préparation des charges de travail d’application pour s’authentifier avec ces informations d’identification. Vous êtes maintenant prêt à déployer votre application et à la configurer pour utiliser l’identité de charge de travail avec la dernière version de la bibliothèque de client Identité Azure. Si vous ne pouvez pas réécrire votre application pour utiliser la dernière version de la bibliothèque de client, vous pouvez configurer votre pod d’application pour vous authentifier en utilisant une identité managée avec une identité de charge de travail comme solution de migration à court terme.