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. Cet article vous montre comment :

• Déployez un cluster AKS à l’aide d’Azure CLI avec l’émetteur OpenID Connect et une identité de charge de travail Microsoft Entra.
• Créer Microsoft Entra Workload ID et un compte de service Kubernetes.
• Configurez l’identité managée pour la fédération de jeton.
• Déployez la charge de travail et vérifiez l’authentification avec l’identité de la charge de travail.
• Accordez éventuellement à un pod dans le cluster l’accès aux secrets dans un coffre de clés Azure.

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.

Prérequis

• Si vous n’avez pas d’abonnement Azure, créez un compte gratuit Azure avant de commencer.
• Cet article nécessite la version 2.47.0 ou ultérieure d’Azure CLI. Si vous utilisez Azure Cloud Shell, la version la plus récente est déjà installée.
• Vérifiez que 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’identifiant d’abonnement approprié dans lequel les ressources doivent être facturées avec la commande az account set.

Définir l’abonnement actif

Tout d’abord, définissez votre abonnement comme abonnement actif actuel en appelant la commande az account set et en passant votre ID d’abonnement.

az account set --subscription <subscription-id>

Exporter des variables d’environnement

Pour simplifier les étapes de configuration des identités requises, les étapes ci-dessous définissent les variables d’environnement référencées dans les exemples de cet article. Pensez à remplacer les valeurs indiquées par vos propres valeurs :

export RESOURCE_GROUP="myResourceGroup"
export LOCATION="eastus"
export CLUSTER_NAME="myAKSCluster"
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"
# Include these variables to access key vault secrets from a pod in the cluster.
export KEYVAULT_NAME="keyvault-workload-id"
export KEYVAULT_SECRET_NAME="my-secret"

Créer un groupe de ressources

Un groupe de ressources Azure est un groupe logique dans lequel des ressources Azure sont déployées et gérées. Lorsque vous créez un groupe de ressources, vous êtes invité à spécifier un emplacement. Cet emplacement est l'emplacement de stockage des métadonnées de votre groupe de ressources et l'endroit où vos ressources s'exécutent dans Azure si vous ne spécifiez pas une autre région lors de la création de la ressource.

Créez un groupe de ressources avec la commande az group create :

az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"

L’exemple de sortie suivant montre la création réussie d’un groupe de ressources :

{
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",
  "location": "eastus",
  "managedBy": null,
  "name": "myResourceGroup",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null
}

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 activer l’émetteur OIDC. L’exemple suivant crée un cluster contenant un nœud unique :

az aks create \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --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.

Mettre à jour un cluster AKS existant

Vous pouvez mettre à jour un cluster AKS afin qu’il utilise l’émetteur OIDC et activer l’identité de charge de travail à l’aide de la commande az aks update avec les paramètres --enable-oidc-issuer et --enable-workload-identity. L’exemple suivant met à jour un cluster existant :

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --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 :

export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv)"

La variable d’environnement 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/

Par défaut, l’émetteur est défini 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 générée de manière aléatoire pour chaque cluster immuable.

Créer une identité managée

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

Ensuite, créez une variable pour l’ID client de l’identité managée.

export USER_ASSIGNED_CLIENT_ID="$(az identity show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --query 'clientId' \
    --output 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 --name "${CLUSTER_NAME}" --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 montre la création réussie de l’identité de charge de travail :

serviceaccount/workload-identity-sa created

Créer les informations d’identification de l’identité fédérée

Utilisez la commande az identity federated-credential create pour créer les informations d’identification de l’identité fédérée entre l’identité managée, l’émetteur du compte de service et le sujet. Pour plus d’informations sur les informations d’identification d’identité fédérée dans Microsoft Entra, consultez Vue d’ensemble des informations d’identification d’identité fédérée dans Microsoft Entra ID.

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

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. Veillez à spécifier une image pour <image> et un nom de conteneur pour <containerName> :

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

Octroyez des autorisations pour accéder à Azure Key Vault

Les instructions de cette étape montrent comment accéder aux secrets, clés ou certificats dans un coffre de clés Azure à partir du pod. Les exemples de cette section configurent l’accès aux secrets dans le coffre de clés pour l’identité de charge de travail, mais vous pouvez effectuer des étapes similaires pour configurer l’accès aux clés ou aux certificats.

L’exemple suivant montre comment utiliser le modèle d’autorisation de contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder au pod l’accès au coffre de clés. Pour plus d’informations sur le modèle d’autorisation RBAC Azure pour Azure Key Vault, consultez Accorder l’autorisation aux applications d’accéder à un coffre de clés Azure à l’aide d’Azure RBAC.

1. Créez un coffre de clés avec la protection contre le vidage et l’autorisation RBAC activée. Vous pouvez également utiliser un coffre de clés existant s’il est configuré pour la protection contre le vidage et l’autorisation RBAC :

   export KEYVAULT_RESOURCE_GROUP="myResourceGroup"
   export KEYVAULT_NAME="myKeyVault"
   
   az keyvault create \
       --name "${KEYVAULT_NAME}" \
       --resource-group "${KEYVAULT_RESOURCE_GROUP}" \
       --location "${LOCATION}" \
       --enable-purge-protection \
       --enable-rbac-authorization
   

2. Attribuez-vous le rôle RBAC Agent des secrets Key Vault afin de pouvoir créer un secret dans le nouveau coffre de clés :

   export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${KEYVAULT_RESOURCE_GROUP}" \
       --name "${KEYVAULT_NAME}" \
       --query id \
       --output tsv)
   
   az role assignment create --assignee "\<user-email\>" \
       --role "Key Vault Secrets Officer" \
       --scope "${KEYVAULT_RESOURCE_ID}"
   

3. Créez un secret dans le coffre de clés :

   export KEYVAULT_SECRET_NAME="my-secret"
   
   az keyvault secret set \
       --vault-name "${KEYVAULT_NAME}" \
       --name "${KEYVAULT_SECRET_NAME}" \
       --value "Hello\!"
   

4. Attribuez le rôle Utilisateur des secrets Key Vault à l’identité managée affectée par l’utilisateur que vous avez créée précédemment. Cette étape donne à l’identité managée l’autorisation de lire les secrets à partir du coffre de clés :

   export IDENTITY_PRINCIPAL_ID=$(az identity show \
       --name "${USER_ASSIGNED_IDENTITY_NAME}" \
       --resource-group "${RESOURCE_GROUP}" \
       --query principalId \
       --output tsv)
   
   az role assignment create \
       --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
       --role "Key Vault Secrets User" \
       --scope "${KEYVAULT_RESOURCE_ID}" \
       --assignee-principal-type ServicePrincipal
   

5. Créez une variable d’environnement pour l’URL du coffre de clés :

   export KEYVAULT_URL="$(az keyvault show \
       --resource-group ${KEYVAULT_RESOURCE_GROUP} \
       --name ${KEYVAULT_NAME} \
       --query properties.vaultUri \
       --output tsv)"
   

6. Déployez un pod qui référence le compte de service et l’URL du coffre de clés :

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-workload-identity-key-vault
     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 sample-workload-identity-key-vault | 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 sample-workload-identity-key-vault

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 "${CLUSTER_NAME}" \
    --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.

L’intégration du connecteur de services permet de simplifier la configuration de la connexion pour les charges de travail AKS et les services de support Azure. Il gère en toute sécurité les configurations réseau et d’authentification et suit les meilleures pratiques de connexion aux services Azure. Pour plus d’informations, consultez Se connecter à Azure OpenAI Service dans AKS à l’aide d’une identité de charge de travail et Introduction au connecteur de services.