Fédération des identités de charge de travail dans Kubernetes avec Azure Arc (préversion)
Les charges de travail logicielles s’exécutant sur des clusters Kubernetes ont besoin d’une identité pour authentifier et accéder aux ressources, ou pour communiquer avec d’autres services. Pour une charge de travail logicielle s’exécutant en dehors d’Azure, vous devez utiliser les informations d’identification de l’application, comme un secret ou un certificat, pour accéder à des ressources protégées par Microsoft Entra (comme Azure Key Vault ou Stockage Blob Azure). Ces informations d’identification présentent un risque de sécurité, et doivent être stockées de façon sécurisée et faire régulièrement l’objet de rotations. Vous courez également le risque d’un arrêt du service si les informations d’identification expirent.
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 d’un fournisseur d’identité externe, comme Kubernetes. L’identité managée affectée par l’utilisateur ou l’inscription d’application dans Microsoft Entra ID devient une identité pour les charges de travail logicielles s’exécutant sur des clusters Kubernetes avec Arc. Une fois cette relation de confiance créée, votre charge de travail logicielle peut échanger des jetons approuvés provenant des clusters Kubernetes avec Arc contre des jetons d’accès de la plateforme d’identités Microsoft. Votre charge de travail logicielle utilise ce jeton d’accès pour accéder aux ressources protégées par Microsoft Entra. Avec la fédération des identités de charge de travail, vous pouvez donc éliminer l’obligation de gérer manuellement les informations d’identification, et supprimer le risque de fuite de secrets ou d’expiration des certificats.
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.
Fonctionnement de la fédération des identités de charge de travail avec des clusters Kubernetes avec Azure Arc
La prise en charge des identités de charge de travail pour Kubernetes avec Azure Arc utilise la projection de volume de jeton de compte de service (c’est-à-dire un compte de service) pour que les pods de charge de travail puissent utiliser une identité Kubernetes. Un jeton Kubernetes est émis, et la fédération OpenID Connect (OIDC) permet aux applications Kubernetes d’accéder aux ressources Azure de façon sécurisée avec Microsoft Entra ID, en se basant sur des comptes de service annotés.
Le cluster Kubernetes avec Arc agit comme l’émetteur de jetons. Microsoft Entra ID utilise OIDC pour découvrir les clés de signature publiques et vérifier l’authenticité du jeton du compte du service avant de l’échanger pour un jeton Microsoft Entra. Votre charge de travail peut échanger un jeton de compte de service projeté sur son volume contre un jeton Microsoft Entra en utilisant la bibliothèque de client Azure Identity ou la bibliothèque d’authentification Microsoft (MSAL).
Le tableau suivant décrit les points de terminaison de l’émetteur OIDC requis pour ID de charge de travail Microsoft Entra.
| Point de terminaison | Description |
|---|---|
{IssuerURL}/.well-known/openid-configuration |
Également appelé document de découverte OIDC. Contient les métadonnées relatives aux configurations de l’émetteur. |
{IssuerURL}/openid/v1/jwks |
Contient la ou les clés de signature publiques que Microsoft Entra ID utilise pour vérifier l’authenticité du jeton du compte de service. |
Étiquettes et annotations de compte de service
ID de charge de travail Microsoft Entra prend en charge les mappages suivants liés à un compte de service :
- Un-à-un : un compte de service référence un objet Microsoft Entra.
- Plusieurs-à-un : plusieurs comptes de service référencent le même objet Microsoft Entra.
- Un-à-plusieurs : un compte de service référence plusieurs objets Microsoft Entra en changeant l’annotation de l’ID client. Pour plus d’informations, consultez Comment fédérer plusieurs identités avec un compte de service Kubernetes.
Spécifications
Les clusters Kubernetes avec Azure Arc prennent en charge ID de charge de travail Microsoft Entra à compter de la version 1.21 de l’agent.
Pour utiliser la fonctionnalité d’identité de charge de travail, vous devez disposer d’Azure CLI version 2.64 ou ultérieure, et de 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 sera installée.
ID de charge de travail Microsoft Entra fonctionne particulièrement bien avec les bibliothèques de client d’Identité Azure ou avec la collection Bibliothèque d’authentification Microsoft (MSAL), en combinaison avec l’inscription d’application. Votre charge de travail peut utiliser n’importe laquelle de ces bibliothèques pour authentifier des ressources cloud Azure et y accéder en toute transparence.
Pour plus d’informations sur l’intégration à des bibliothèques courantes, consultez Utiliser ID de charge de travail Microsoft Entra avec AKS.
Limites actuelles
Gardez à l’esprit les limitations actuelles suivantes :
- Un maximum de 20 informations d’identification d’identité fédérée par identité managée peuvent être configurées.
- Une fois les informations d’identification d’identité fédérée initialement ajoutées, leur propagation prend quelques secondes.
- La création d’informations d’identification d’identité fédérée n’est pas prise en charge sur les identités managées affectées par l’utilisateur dans certaines régions.