Déployer et configurer l’identité de charge de travail sur un cluster AKS activé par le cluster Azure Arc (préversion)

S’applique à : Azure Local, version 23H2

La fédération des identités de charge de travail vous permet de configurer une identité managée affectée par l’utilisateur ou une inscription d’application dans Microsoft Entra ID pour approuver des jetons à partir d’un fournisseur d’identité externe (IDP), tel que Kubernetes, permettant l’accès aux ressources protégées par Microsoft Entra, comme Azure Key Vault ou le stockage Blob Azure.

Azure Kubernetes Service (AKS) activé par Azure Arc est un service Kubernetes managé qui vous permet de déployer facilement des clusters Kubernetes compatibles avec l’identité de charge de travail. Cet article explique comment effectuer les tâches suivantes :

• Créez un cluster AKS Arc avec l’identité de charge de travail activée (préversion).
• Créez un compte de service Kubernetes et liez-le à l’identité managée Azure.
• Créez des informations d’identification fédérées sur l’identité managée pour approuver l’émetteur OIDC.
• Déployez votre application.
• Exemple : Accordez à un pod dans le cluster l’accès aux secrets dans un coffre de clés Azure.

Pour avoir une vue d’ensemble conceptuelle de la fédération d’identité des charges de travail, veuillez consulter la section Fédération des identités de charge de travail dans Kubernetes avec Azure Arc (préversion).

Prérequis

Avant de déployer un cluster Kubernetes avec Azure Arc activé, vous devez disposer des conditions préalables suivantes :

• Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
• Cet article nécessite la version 1.4.23 ou ultérieure d’Azure CLI. Si vous utilisez Azure Cloud Shell, sachez que la version la plus récente est déjà installée.

Exporter des variables d’environnement

Pour simplifier les étapes de configuration des identités requises, les commandes suivantes définissent des variables d’environnement référencées dans les exemples de cet article. Remplacez les valeurs suivantes par les vôtres :

$AZSubscriptionID = "00000000-0000-0000-0000-000000000000" 
$Location = "westeurope" 
$resource_group_name = "myResourceGroup" 

$aks_cluster_name = "myAKSCluster" 

$SERVICE_ACCOUNT_NAMESPACE = "default" 
$SERVICE_ACCOUNT_NAME = "workload-identity-sa" 

$FedIdCredentialName = "myFedIdentity" 
$MSIName = "myIdentity" 

# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

Définir l’abonnement actif

Tout d’abord, définissez votre abonnement comme abonnement actif actuel. Exécutez la commande az account set avec votre ID d’abonnement :

az login  
az account set -s $AZSubscriptionID

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.

Exécutez la commande az group create pour créer un groupe de ressources :

az group create --name $resource_group_name --location $Location

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

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

Étape 1 : Créer un cluster AKS Arc avec l’identité de charge de travail activée

Pour créer un cluster AKS Arc, vous avez besoin des valeurs et $customlocation_ID des $logicnet_Id valeurs.

• $customlocation_ID: ID Azure Resource Manager de l’emplacement personnalisé. L’emplacement personnalisé est configuré pendant le déploiement du cluster Azure Local version 23H2. Votre administrateur d’infrastructure doit vous donner l’ID Resource Manager de l’emplacement personnalisé. Vous pouvez également obtenir l’ID Resource Manager à l’aide $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv)de , si l’administrateur de l’infrastructure fournit un nom d’emplacement personnalisé et un nom de groupe de ressources.
• $logicnet_Id: ID Azure Resource Manager du réseau logique Local Azure créé en suivant ces étapes. Votre administrateur d’infrastructure doit vous donner l’ID Resource Manager du réseau logique. Vous pouvez également obtenir l’ID Resource Manager à l’aide $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv)de , si l’administrateur de l’infrastructure fournit un nom de réseau logique et un nom de groupe de ressources.

Exécutez la commande az aksarc create avec le --enable-oidc-issuer --enable-workload-identity paramètre. Fournissez vos ID entra-admin-group-object-ids et vérifiez que vous êtes membre du groupe d’administration Microsoft Entra ID pour l’accès en mode proxy :

az aksarc create  
-n $aks_cluster_name -g $resource_group_name  
--custom-location $customlocation_ID --vnet-ids $logicnet_Id  
--aad-admin-group-object-ids <entra-admin-group-object-ids> 
--generate-ssh-keys  
--enable-oidc-issuer --enable-workload-identity

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

L’extension d’identité de charge de travail peut prendre un certain temps après la création d’un cluster provisionné. Utilisez la commande suivante pour vérifier l’état de l’extension d’identité de charge de travail :

az connectedk8s show -n $aks_cluster_name -g $resource_group_name

# agentState = "Succeeded" 
"agentPublicKeyCertificate": "", 
  "agentVersion": "1.21.10", 
  "arcAgentProfile": { 
    "agentAutoUpgrade": "Enabled", 
    "agentErrors": [], 
    "agentState": "Succeeded", 
    "desiredAgentVersion": "", 
    "systemComponents": null 

# oidcIssuerProfile "enabled": true and "issuerUrl" present 

"oidcIssuerProfile": { 
    "enabled": true, 
    "issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/"}

Dans le Portail Azure, vous pouvez afficher l’extension wiextension sous la section Propriétés de votre cluster Kubernetes.

Enregistrer l’URL de l’émetteur OIDC dans une variable d’environnement

Une fois le cluster AKS créé, vous pouvez obtenir l’URL de l’émetteur OIDC et l’enregistrer dans une variable d’environnement. Exécutez la commande suivante :

$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)

Étape 2 : Créer un compte de service Kubernetes et le lier à l’identité managée Azure

Tout d’abord, créez une identité managée. Exécutez la commande az identity create :

az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID

Ensuite, créez des variables pour l’ID client de l’identité managée :

$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --output tsv)

Créer un compte de service Kubernetes

Dans cette étape, vous allez créer un compte de service Kubernetes et l’annoter avec l’ID client de l’identité managée que vous avez créée à l’étape précédente.

Utilisez la connexion au cluster pour accéder à votre cluster à partir d’un appareil client. Pour plus d’informations, consultez Accéder à votre cluster à partir d’un appareil client:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Ouvrez une nouvelle fenêtre de commande CLI. Copiez et collez les commandes suivantes :

$yaml = @"
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: $MSIId
  name: $SERVICE_ACCOUNT_NAME
  namespace: $SERVICE_ACCOUNT_NAMESPACE
"@

$yaml = $yaml -replace '\$MSIId', $MSIId `
               -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME `
               -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE

$yaml | kubectl apply -f -

La sortie suivante montre la création réussie du compte de service :

serviceaccount/workload-identity-sa created

Étape 3 : Créer des informations d’identification fédérées sur l’identité managée pour approuver l’émetteur OIDC

Tout d’abord, créez 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 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.

# Create a federated credential 

az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}" 

# Show the federated credential 

az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName

Étape 4 : 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 et metadata\namespace les spec\serviceAccountName propriétés. Veillez à spécifier une image pour image et un nom de conteneur pour containerName :

$image = "<image>"  # Replace <image> with the actual image name 
$containerName = "<containerName>"  # Replace <containerName> with the actual container name 

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  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 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME 

# Apply the YAML configuration 
$yaml | kubectl apply -f - 

Exemple : Accorder des autorisations pour accéder à Azure Key Vault

Les instructions de cette étape décrivent 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 :

   az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization
   
   # retrieve the key vault ID for role assignment
   $KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)
   

2. Attribuez le rôle Agent de secrets RBAC Key Vault à vous-même afin de pouvoir créer un secret dans le nouveau coffre de clés. Les nouvelles attributions de rôles peuvent prendre jusqu’à cinq minutes pour se propager et être mises à jour par le serveur d’autorisation.

   $CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
   
   az role assignment create --assignee-object-id $CALLER_OBJECT_ID --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
   

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

   az keyvault secret set --vault-name $KVName --name $KVSecretName --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 :

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

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

   $KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --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 :

   $yaml = @" 
   apiVersion: v1 
   kind: Pod 
   metadata: 
     name: sample-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: $KVUrl 
         - name: SECRET_NAME 
           value: $KVSecretName 
     nodeSelector: 
       kubernetes.io/os: linux 
   "@ 
   
   # Replace variables within the YAML content 
   $yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                   -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
                   -replace '\$KVUrl', $KVUrl ` 
                   -replace '\$KVSecretName', $KVSecretName 
   
   # Apply the YAML configuration 
   $yaml | kubectl --kubeconfig <path-to-aks-cluster-kubeconfig> apply -f -
   

Supprimer un cluster AKS Arc

Pour supprimer le cluster AKS Arc, utilisez la commande az aksarc delete :

az aksarc delete -n $aks_cluster_name -g $resource_group_name

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