Configurer l’identité de charge de travail sur un cluster AKS Edge Essentials (préversion)

Article
11/16/2024

Azure Kubernetes Service (AKS) Edge Essentials est une implémentation Kubernetes locale d’Azure Kubernetes Service (AKS) qui automatise l’exécution d’applications conteneurisées à grande échelle. Cet article explique comment effectuer les tâches suivantes :

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 obtenir une vue d’ensemble conceptuelle de la fédération des identités de charge de travail, consultez La fédération des identités de charge de travail dans Kubernetes avec Azure Arc (préversion).

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. Les préversions d’Azure Kubernetes Service Edge Essentials sont partiellement couvertes par le support client sur une base optimale.

Remarque

Dans cette préversion publique, AKS Edge Essentials vous permet d’activer l’identité de charge de travail pendant le déploiement initial du script de démarrage rapide Azure IoT Operations. Cette fonctionnalité n’est pas disponible pour d’autres scénarios AKS Edge Essentials.

Prérequis

Avant d’utiliser la fédération des identités de charge de travail pour un cluster AKS Edge Essentials, vous devez déployer le script de démarrage rapide Azure IoT Operation, comme décrit dans Créer et configurer un cluster AKS Edge Essentials qui peut exécuter des opérations Azure IoT. Le script active automatiquement la fonctionnalité de fédération des identités de charge de travail sur le cluster AKS Edge Essentials.

Après avoir déployé le cluster AKS Edge Essentials, vous pouvez utiliser 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/", 

# workloadIdentity "enabled": true 
"securityProfile": { 
    "workloadIdentity": { 
      "enabled": true

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

Exporter des variables d’environnement

Pour simplifier les étapes de configuration des identités requises, les étapes suivantes 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 :

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

# Include these variables to access key vault secrets from a pod in the cluster. 
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

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

Pour 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 1 : Créer un compte de service Kubernetes et le lier à l’identité managée Azure

Tout d’abord, appelez la commande az identity create pour créer une identité managée :

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 que vous avez créée à l’étape précédente. Copiez et collez les commandes Azure CLI suivantes :

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

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

# Apply the YAML content to Kubernetes 
$yaml | kubectl apply -f -

La sortie suivante montre l’identité de charge de travail créée avec succès :

serviceaccount/workload-identity-sa created

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

Pour créer les informations d’identification d’identité fédérée entre l’identité managée, l’émetteur du compte de service et l’objet, appelez la commande az identity federated-credential create . 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 3 : 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 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