Déployer et configurer la fédération des identités de charge de travail dans Kubernetes avec Azure Arc (préversion)
Vous pouvez activer la fonctionnalité d’identité de charge de travail sur un cluster Kubernetes avec Azure Arc en utilisant l’interface Azure CLI. Le processus suit ces étapes générales :
- Activer la fonctionnalité d’identité de charge de travail sur un cluster Kubernetes avec Arc nouveau ou existant.
- Créer une identité managée (ou une inscription d’application) et un compte de service Kubernetes.
- Configurez l’identité managée pour la fédération de jeton.
- Configurer des annotations de compte de service et des étiquettes de pod d’application pour utiliser l’identité de charge de travail.
- Configurer les paramètres d’identité de charge de travail sur le cluster Kubernetes.
- Désactiver l’identité de charge de travail sur le cluster.
Pour obtenir une vue d’ensemble de cette fonctionnalité, consultez Fédération des identités de charge de travail dans Kubernetes avec Azure Arc (préversion).
Important
La fonctionnalité de fédération des identités de charge de travail Azure Arc est actuellement en préversion. Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.
Conseil
Cet article décrit les étapes requises pour déployer et configurer l’identité de charge de travail sur un cluster Kubernetes avec Arc. Pour savoir comment activer l’identité de charge de travail sur d’autres types de clusters, consultez les articles suivants :
Prérequis
- L’identité de charge de travail pour les clusters Kubernetes avec Azure Arc (préversion) est prise en charge sur les distributions Kubernetes suivantes :
- Cluster Ubuntu Linux exécutant K3s
- AKS sur Edge Essentials
- AKS sur HCI 23H2
Pour utiliser la fonctionnalité d’identité de charge de travail, vous devez avoir Azure CLI version 2.64 ou ultérieure et az connectedk8s
version 1.10.0 ou ultérieure. Veillez à mettre à jour votre version d’Azure CLI avant de mettre à jour votre version de az connectedk8s
. Si vous utilisez Azure Cloud Shell, la dernière version d’Azure CLI est installée.
Activer l’identité de charge de travail sur votre cluster
Suivez les étapes appropriées pour activer la fonctionnalité d’identité de charge de travail pour un cluster Kubernetes avec Arc, nouveau ou existant. Dans les deux cas, veillez à remplacer le nom et le groupe de ressources par vos valeurs et à configurer les paramètres comme vous le souhaitez.
Paramètre | Description | Obligatoire |
---|---|---|
--enable-oidc-issuer |
Génère et héberge l’URL de l’émetteur OIDC, une URL accessible publiquement qui permet au serveur d’API de rechercher des clés de signature publiques pour vérifier les jetons. | Requis |
--enable-workload-identity |
Installe un webhook d’admission mutant qui projette un jeton de compte de service signé vers un chemin d’accès connu et injecte des variables d’environnement liées à l’authentification dans les pods d’application en fonction des paramètres du compte de service annoté. Pour un nouveau cluster, si ce paramètre n’est pas activé, vous devez monter un volume projeté sur un chemin d’accès connu qui expose le jeton de compte de service signé au chemin d’accès. | Facultatif |
Définir des variables d’environnement
Pour vous faciliter la tâche, les variables d’environnement définies ci-dessous sont référencées dans les exemples de cet article. Remplacez ces valeurs par vos propres valeurs :
export RESOURCE_GROUP="myRG"
export LOCATION="eastus"
export CLUSTER_NAME="mycluster"
export SERVICE_ACCOUNT_NAMESPACE="myKubernetesnamespace"
export SERVICE_ACCOUNT_NAME="mysa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"
Pour créer un cluster avec Azure Arc avec l’identité de charge de travail activée, utilisez la commande suivante :
az connectedk8s connect --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" --enable-oidc-issuer –-enable-workload-identity
Pour activer l’identité de charge de travail sur un cluster Kubernetes avec Arc existant, utilisez la commande update
.
az connectedk8s update --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" --enable-oidc-issuer --enable-workload-identity
Obtenir l’URL de l’émetteur OIDC
Récupérez (fetch) l’URL de l’émetteur OIDC et enregistrez-la dans une variable d’environnement. Vous aurez besoin de cette URL d’émetteur à la prochaine étape.
export OIDC_ISSUER="$(az connectk8s show --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" \
--query "oidcIssuerProfile.issuerUrl" \
--output tsv)"
Pour afficher la variable d’environnement, entrez echo ${OIDC_ISSUER}
. La variable d’environnement doit contenir l’URL de l’émetteur, comme décrit dans l’exemple suivant :
https://northamerica.oic.prod-arc.azure.com/00000000-0000-0000-0000-000000000000/12345678-1234-1234-1234-123456789123/
Par défaut, l’émetteur est configuré pour utiliser l’URL de base https://{region}.oic.prod-arc.azure.com/{tenant_id}/{uuid}
, où la valeur de {region}
correspond à l’emplacement de création du cluster Kubernetes avec Arc. La valeur {uuid}
représente la clé OIDC (OpenID Connect), qui est un GUID immuable et généré de manière aléatoire pour chaque cluster.
Créer une identité managée
Utilisez la commande az identity create
pour créer une identité managée affectée par l’utilisateur. Avec l’identité de charge de travail, une relation d’approbation est établie entre le jeton de l’identité de gestion affectée par l’utilisateur et le jeton de compte de service du cluster Kubernetes.
az identity create \
--name "${USER_ASSIGNED_IDENTITY_NAME}" \
--resource-group "${RESOURCE_GROUP}" \
--location "${LOCATION}" \
--subscription "${SUBSCRIPTION}"
Récupérez l’ID client de l’identité managée et stockez-le dans une variable d’environnement.
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. Les jetons signés associés au compte de service Kubernetes sont échangés contre un jeton Microsoft Entra ID une fois la relation d’approbation établie entre les deux.
Appliquez l’extrait de code YAML suivant pour créer un compte de service avec l’annotation d’identité de charge de travail ajoutée.
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}"
name: "${SERVICE_ACCOUNT_NAME}"
namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
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 d’identité fédérée entre l’identité managée, l’émetteur du compte de service et le sujet. Cette étape établit la relation d’approbation entre le cluster Kubernetes et Microsoft Entra pour l’échange de jetons. 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 "${OIDC_ISSUER}" \
--subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \
--audience api://AzureADTokenExchange
Remarque
Une fois les informations d’identification d’identité fédérée ajoutées, la propagation prend quelques secondes. 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, ajoutez un léger délai dans vos scripts après l’ajout des informations d’identification d’identité fédérée.
Configurer les annotations de compte de service et les étiquettes de pod
Les annotations de compte de service et de pod suivantes sont disponibles pour configurer l’identité de charge de travail en fonction des exigences de l’application. L’étiquette de pod spécifiée ci-dessous est obligatoire si –-enable-workload-identity
est défini sur true
.
Annotations de compte de service
Toutes les annotations de compte de service sont facultatives. Si aucune annotation n’est spécifiée, la valeur par défaut est utilisée.
Annotation | Description | Default |
---|---|---|
azure.workload.identity/client-id |
ID client de l’application Microsoft Entra à utiliser avec le pod. | |
azure.workload.identity/tenant-id |
ID de locataire Azure où l’application Microsoft Entra est inscrite. | Variable d’environnement AZURE_TENANT_ID extraite de ConfigMap azure-wi-webhook-config . |
azure.workload.identity/service-account-token-expiration |
Champ expirationSeconds pour le jeton de compte de service projeté. Configurez-le pour éviter les temps d’arrêt causés par des erreurs lors de l’actualisation du jeton de compte de service. L’expiration du jeton de compte de service Kubernetes n’est pas corrélée avec les jetons Microsoft Entra. Les jetons Microsoft Entra expirent 24 heures après leur émission. |
3 600 (la plage prise en charge va de 3 600 à 86 400) |
Étiquettes du pod
Annotation | Description | Valeur recommandée | Requis |
---|---|---|---|
azure.workload.identity/use |
Obligatoire dans la spec de modèle du pod. Si –-enable-workload-identity est défini sur true , seuls les pods avec cette étiquette sont mutés par le webhook d’admission mutant pour injecter les variables d’environnement spécifiques à Azure et le volume de jeton de compte de service projeté. |
true |
Oui |
Annotations de pod
Toutes les annotations de pod sont facultatives. Si aucune annotation n’est spécifiée, la valeur par défaut est utilisée.
Annotation | Description | Default |
---|---|---|
azure.workload.identity/service-account-token-expiration |
Champ expirationSeconds pour le jeton de compte de service projeté. Configurez-le pour éviter les temps d’arrêt causés par des erreurs lors de l’actualisation du jeton de compte de service. L’expiration du jeton de compte de service Kubernetes n’est pas corrélée avec les jetons Microsoft Entra. Les jetons Microsoft Entra expirent 24 heures après leur émission. |
3 600 (la plage prise en charge va de 3 600 à 86 400) |
azure.workload.identity/skip-containers |
Représente une liste de conteneurs séparés par des points-virgules pour ignorer l’ajout d’un volume de jeton de compte de service projeté. Par exemple : container1;container2 . |
Par défaut, le volume de jeton de compte de service projeté est ajouté à tous les conteneurs si le pod est étiqueté avec azure.workload.identity/use: true . |
Configurer les paramètres d’identité de charge de travail sur le cluster Kubernetes
Le serveur d’API sur le cluster Kubernetes doit être configuré pour émettre des jetons de compte de service qui incluent l’URL de l’émetteur OIDC accessible publiquement (afin qu’Entra sache où trouver les clés publiques pour valider le jeton).
Pour configurer les paramètres d’identité de charge de travail sur Ubuntu Linux avec K3s, effectuez les étapes ci-dessous pour terminer la configuration :
Créez un fichier config k3s.
Modifiez
/etc/rancher/k3s/config.yaml
pour ajouter les paramètres suivants :`kube-apiserver-arg: - 'service-account-issuer=${OIDC_ISSUER}' - 'service-account-max-token-expiration=24h'`
Enregistrez le fichier config.yaml.
Redémarrez le serveur d’API k3s à l’aide de la commande
systemctl restart k3s
.Nous vous recommandons d’effectuer fréquemment la rotation des clés de compte de service. Pour plus d’informations, consultez Rotation des clés d’émetteur de compte de service.
Désactiver l’identité de charge de travail
Pour désactiver la fonctionnalité d’identité de charge de travail sur un cluster Kubernetes avec Azure Arc, exécutez la commande suivante :
az connectedk8s update
--resource-group "${RESOURCE_GROUP}"
--name "${CLUSTER_NAME}"
--disable-workload-identity