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

Article
11/23/2024

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.

Important

Ces fonctionnalités en préversion sont disponibles en libre-service, en mode opt-in. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Azure Kubernetes Service, activé par les préversions d’Azure Arc, est partiellement couvert par le support client sur une base optimale.

Remarque

En préversion publique, AKS sur Azure Stack HCI prend en charge l’activation de l’identité de charge de travail lors de la création du cluster AKS. Toutefois, l’activation de l’identité de charge de travail après sa création ou sa désactivation ultérieurement n’est pas prise en charge.

Prérequis

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

Si vous n’en avez pas, créez un compte gratuit Azure 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 $logicnet_Id des $customlocation_ID valeurs.

$customlocation_ID: ID Azure Resource Manager de l’emplacement personnalisé. L’emplacement personnalisé est configuré pendant le déploiement du cluster Azure Stack HCI. 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.

Important

Dans le cadre de l’amélioration de la sécurité pour les clusters AKS Arc, l’activation de l’identité de charge de travail déclenche deux modifications. Tout d’abord, la clé de signature du compte Kubernetes service pivote automatiquement toutes les 45 jours et reste valide pendant 90 jours. Deuxièmement, l’indicateur --service-account-extend-token-expiration est désactivé, réduisant la validité des jetons d’un an à un maximum de 24 heures.

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

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 :

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Ouvrez une nouvelle fenêtre. Copiez et collez les commandes CLI 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

Remarque

Après avoir ajouté des informations d’identification d’identité fédérée, la propagation prend quelques secondes. Les demandes de jeton effectuées immédiatement après peuvent échouer jusqu’à l’actualisation du cache. Pour éviter ce problème, envisagez d’ajouter un bref délai après la création des informations d’identification d’identité fédérée.

É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 spec\serviceAccountName les metadata\namespace 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 -

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. Sinon, les pods échouent après leur redémarrage.

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.

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)

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.
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
```

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

az keyvault secret set --vault-name $KVName --name $KVSecretName --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 :
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
```

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)

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 $aks_cluster_name apply -f -

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

Partager via

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

Prérequis

Exporter des variables d’environnement

Définir l’abonnement actif

Créer un groupe de ressources

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

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

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

Créer un compte de service Kubernetes

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

Étape 4 : Déployer votre application

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

Étapes suivantes

Commentaires

Ressources supplémentaires