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

Article
08/02/2024

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.

Remarque

Vous pouvez utiliser le Connecteur de services pour vous aider à configurer automatiquement certaines étapes. 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.

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.

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

Remarque

Il faut quelques secondes pour que les informations d’identification de l’identité fédérée se propagent après avoir été ajoutées. Si une demande de jeton est effectuée immédiatement après l’ajout des informations d’identification de l’identité fédérée, la demande peut échouer jusqu’à ce que le cache soit actualisé. 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. 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

Important

Vérifiez que les pods d’application utilisant l’identité de charge de travail incluent l’étiquette azure.workload.identity/use: "true" dans la spécification du pod. Dans le cas contraire, les pods échouent après avoir été redémarrés.

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.

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

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

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

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

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

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

Important

Les attributions de rôle RBAC Azure peuvent prendre jusqu’à dix minutes pour se propager. Si le pod ne parvient pas à accéder au secret, vous devrez peut-être attendre que l’attribution de rôle se propage. Pour plus d’informations, consultez Résoudre les problèmes liés à RBAC Azure.

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.

Partage via

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

Prérequis

Définir l’abonnement actif

Exporter des variables d’environnement

Créer un groupe de ressources

Créer un cluster AKS

Mettre à jour un cluster AKS existant

Obtenir l’URL de l’émetteur OIDC

Créer une identité managée

Créer un compte de service Kubernetes

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

Déployer votre application

Octroyez des autorisations pour accéder à Azure Key Vault

Désactiver l’identité de charge de travail

Étapes suivantes

Ressources supplémentaires