Utiliser kubelogin pour authentifier les utilisateurs dans Azure Kubernetes Service
Le plug-in kubelogin dans Azure est un plug-in d’informations d’identification d’accès client qui implémente l’authentification Microsoft Entra. Le plug-in kubelogin offre des fonctionnalités qui ne sont pas disponibles dans l’outil en ligne de commande kubectl.
Les clusters Azure Kubernetes Service (AKS) intégrés à Microsoft Entra ID et exécutant Kubernetes version 1.24 ou ultérieure utilisent automatiquement le format kubelogin.
Cet article fournit une vue d’ensemble et des exemples d’utilisation de kubelogin pour toutes les méthodes d’authentification Microsoft Entra prises en charge dans AKS.
Limites
- Vous pouvez inclure un maximum de 200 groupes dans une revendication Microsoft Entra JSON Web Token (JWT). Si vous avez plus de 200 groupes, envisagez d’utiliser des rôles d’application.
- Les groupes créés dans Microsoft Entra ID sont inclus uniquement par leur valeur ObjectID , et non par leur nom complet. La
sAMAccountName
commande est disponible uniquement pour les groupes synchronisés à partir de Windows Server Active Directory local. - Dans AKS, la méthode d’authentification du principal de service fonctionne uniquement avec l’ID Microsoft Entra managé, et non avec la version antérieure d’Azure Active Directory.
- La méthode d’authentification du code d’appareil ne fonctionne pas lorsqu’une stratégie d’accès conditionnel Microsoft Entra est définie sur un locataire Microsoft Entra. Dans ce scénario, utilisez l’authentification interactive du navigateur web.
Fonctionnement de l’authentification
Pour la plupart des interactions avec kubelogin, vous utilisez la convert-kubeconfig
sous-commande. La sous-commande utilise le fichier kubeconfig spécifié dans --kubeconfig
ou dans la KUBECONFIG
variable d’environnement pour convertir le fichier kubeconfig final au format exec en fonction de la méthode d’authentification spécifiée.
Les méthodes d’authentification implémentées par kubelogin sont des flux d’octroi de jetons Microsoft Entra OAuth 2.0. Les indicateurs de paramètre suivants sont courants à utiliser dans les sous-commandes kubelogin. En général, ces indicateurs sont prêts à être utilisés lorsque vous obtenez le fichier kubeconfig à partir d’AKS.
--tenant-id
: ID de locataire Microsoft Entra.--client-id
: ID d’application de l’application cliente publique. Cette application cliente est utilisée uniquement dans le code de l’appareil, le navigateur web interactif et les méthodes de connexion ROPC (Resource Owner Password Credentials) (ROPC) (Resource Owner Password Credentials) OAuth 2.0.--server-id
: ID d’application de l’application web ou du serveur de ressources. Le jeton est émis à cette ressource.
Remarque
Dans chaque méthode d’authentification, le jeton n’est pas mis en cache sur le système de fichiers.
Méthodes d’authentification
Les sections suivantes décrivent les méthodes d’authentification prises en charge et comment les utiliser :
- Code d’appareil
- Azure CLI
- Navigateur web interactif
- Principal du service
- Identité managée
- Identité de la charge de travail
Code d’appareil
Le code de l’appareil est la méthode d’authentification par défaut pour la convert-kubeconfig
sous-commande. Le paramètre -l devicecode
est facultatif. Cette méthode d’authentification invite l’utilisateur à se connecter à partir d’une session de navigateur.
Avant l’introduction des plug-ins kubelogin et exec, la méthode d’authentification Azure dans kubectl ne prend en charge que le flux de code de l’appareil. Il a utilisé une version antérieure d’une bibliothèque qui produit un jeton qui a la audience
revendication avec un spn:
préfixe. Il n’est pas compatible avec l’ID Microsoft Entra géré par AKS, qui utilise un flux OBO (on-behalf-of). Lorsque vous exécutez la convert-kubeconfig
sous-commande, kubelogin supprime le spn:
préfixe de la revendication d’audience.
Si vos besoins incluent l’utilisation de fonctionnalités de versions antérieures, ajoutez l’argument --legacy
. Si vous utilisez le fichier kubeconfig dans un cluster Azure Active Directory version antérieure, kubelogin ajoute automatiquement l’indicateur --legacy
.
Dans cette méthode de connexion, le jeton d’accès et le jeton d’actualisation sont mis en cache dans le répertoire ${HOME}/.kube/cache/kubelogin . Pour remplacer ce chemin, incluez le --token-cache-dir
paramètre.
Si votre cluster intégré AKS Microsoft Entra utilise Kubernetes 1.24 ou version antérieure, vous devez convertir manuellement le format de fichier kubeconfig en exécutant les commandes suivantes :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Pour propre des jetons mis en cache, exécutez la commande suivante :
kubelogin remove-tokens
Remarque
La méthode de connexion au code de l’appareil ne fonctionne pas lorsqu’une stratégie d’accès conditionnel est configurée sur un locataire Microsoft Entra. Dans ce scénario, utilisez la méthode interactive du navigateur web.
Azure CLI
La méthode d’authentification Azure CLI utilise le contexte connecté établi par Azure CLI pour obtenir le jeton d’accès. Le jeton est émis dans le même locataire Microsoft Entra que az login
. kubelogin n’écrit pas de jetons dans le fichier de cache de jetons, car ils sont déjà gérés par Azure CLI.
Remarque
Cette méthode d’authentification fonctionne uniquement avec l’ID Microsoft Entra géré par AKS.
L’exemple suivant montre comment utiliser la méthode Azure CLI pour s’authentifier :
az login
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l azurecli
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Si le répertoire de configuration Azure CLI se trouve en dehors du répertoire ${HOME} , utilisez le --azure-config-dir
paramètre avec la convert-kubeconfig
sous-commande. La commande génère le fichier kubeconfig avec la variable d’environnement configurée. Vous pouvez obtenir la même configuration en définissant la AZURE_CONFIG_DIR
variable d’environnement sur ce répertoire lorsque vous exécutez une commande kubectl.
Navigateur web interactif
La méthode interactive du navigateur web d’authentification ouvre automatiquement un navigateur web pour se connecter à l’utilisateur. Une fois l’utilisateur authentifié, le navigateur redirige vers le serveur web local à l’aide des informations d’identification vérifiées. Cette méthode d’authentification est conforme à la stratégie d’accès conditionnel.
Lorsque vous vous authentifiez à l’aide de cette méthode, le jeton d’accès est mis en cache dans le répertoire ${HOME}/.kube/cache/kubelogin . Vous pouvez remplacer ce chemin à l’aide du --token-cache-dir
paramètre.
Jeton du porteur
L’exemple suivant montre comment utiliser un jeton du porteur avec le flux interactif du navigateur web :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l interactive
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Jeton de preuve de possession
L’exemple suivant montre comment utiliser un jeton de preuve de possession (PoP) avec le flux interactif du navigateur web :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l interactive --pop-enabled --pop-claims "u=/ARM/ID/OF/CLUSTER"
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Principal du service
Cette méthode d’authentification utilise un principal de service pour connecter l’utilisateur. Vous pouvez fournir les informations d’identification en définissant une variable d’environnement ou en utilisant les informations d’identification dans un argument de ligne de commande. Les informations d’identification prises en charge que vous pouvez utiliser sont un mot de passe ou un certificat client PFX (Personal Information Exchange).
Avant d’utiliser cette méthode, tenez compte des limitations suivantes :
- Cette méthode fonctionne uniquement avec l’ID Microsoft Entra managé.
- Le principal de service peut être membre d’un maximum de 200 groupes Microsoft Entra.
Variables d'environnement
L’exemple suivant montre comment configurer une clé secrète client à l’aide de variables d’environnement :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l spn
export AAD_SERVICE_PRINCIPAL_CLIENT_ID=<Service Principal Name (SPN) client ID>
export AAD_SERVICE_PRINCIPAL_CLIENT_SECRET=<SPN secret>
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Ensuite, exécutez cette commande :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l spn
export AZURE_CLIENT_ID=<SPN client ID>
export AZURE_CLIENT_SECRET=<SPN secret>
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Argument de ligne de commande
L’exemple suivant montre comment configurer un secret client dans un argument de ligne de commande :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l spn --client-id <SPN client ID> --client-secret <SPN client secret>
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Avertissement
La méthode d’argument de ligne de commande stocke le secret dans le fichier kubeconfig.
Certificat client
L’exemple suivant montre comment configurer une clé secrète client à l’aide d’un certificat client :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l spn
export AAD_SERVICE_PRINCIPAL_CLIENT_ID=<SPN client ID>
export AAD_SERVICE_PRINCIPAL_CLIENT_CERTIFICATE=/path/to/cert.pfx
export AAD_SERVICE_PRINCIPAL_CLIENT_CERTIFICATE_PASSWORD=<PFX password>
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Ensuite, exécutez cette commande :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l spn
export AZURE_CLIENT_ID=<SPN client ID>
export AZURE_CLIENT_CERTIFICATE_PATH=/path/to/cert.pfx
export AZURE_CLIENT_CERTIFICATE_PASSWORD=<PFX password>
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Jeton poP et variables d’environnement
L’exemple suivant montre comment configurer un jeton PoP qui utilise une clé secrète client qu’il obtient à partir de variables d’environnement :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l spn --pop-enabled --pop-claims "u=/ARM/ID/OF/CLUSTER"
export AAD_SERVICE_PRINCIPAL_CLIENT_ID=<SPN client ID>
export AAD_SERVICE_PRINCIPAL_CLIENT_SECRET=<SPN secret>
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Identité gérée
Utilisez la méthode d’authentification d’identité managée pour les applications qui se connectent aux ressources qui prennent en charge l’authentification Microsoft Entra. Par exemple, l’accès aux ressources Azure comme une machine virtuelle Azure, un groupe de machines virtuelles identiques ou Azure Cloud Shell.
Identité managée par défaut
L’exemple suivant montre comment utiliser l’identité managée par défaut :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l msi
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Identité spécifique
L’exemple suivant montre comment utiliser une identité managée avec une identité spécifique :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l msi --client-id <msi-client-id>
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Identité de la charge de travail
La méthode d’authentification des identités de charge de travail utilise des informations d’identification d’identité fédérées avec Microsoft Entra pour authentifier l’accès aux clusters AKS. La méthode utilise l’authentification intégrée Microsoft Entra. Il fonctionne en définissant les variables d’environnement suivantes :
AZURE_CLIENT_ID
: ID d’application Microsoft Entra fédéré avec l’identité de charge de travail.AZURE_TENANT_ID
: ID de locataire Microsoft Entra.AZURE_FEDERATED_TOKEN_FILE
: fichier qui contient une assertion signée de l’identité de charge de travail, comme un jeton de compte de service projeté Kubernetes (JWT).AZURE_AUTHORITY_HOST
: URL de base d’une autorité Microsoft Entra. Par exemple :https://login.microsoftonline.com/
.
Vous pouvez utiliser une identité de charge de travail pour accéder aux clusters Kubernetes à partir de systèmes CI/CD tels que GitHub ou ArgoCD sans stocker les informations d’identification du principal de service dans les systèmes externes. Pour configurer la fédération OpenID Connecter (OIDC) à partir de GitHub, consultez l’exemple de fédération OIDC.
L’exemple suivant montre comment utiliser une identité de charge de travail :
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig -l workloadidentity
Exécutez cette commande kubectl pour obtenir des informations sur le nœud :
kubectl get nodes
Comment utiliser kubelogin avec AKS
AKS utilise une paire d’applications Microsoft Entra internes. Ces ID d’application sont les mêmes dans tous les environnements.
L’ID d’application serveur AKS Microsoft Entra que le côté serveur utilise est 6dae42f8-4368-4678-94ff-3960e28e3630
. Le jeton d’accès qui accède aux clusters AKS doit être émis pour cette application. Dans la plupart des méthodes d’authentification kubelogin, vous devez utiliser --server-id
avec kubelogin get-token
.
L’ID d’application cliente AKS Microsoft Entra que kubelogin utilise pour effectuer l’authentification du client public pour le compte de l’utilisateur est 80faf920-1908-4b52-b5ef-a8e7bedfc67a
. L’ID d’application cliente est utilisé dans les méthodes d’authentification interactive du code de l’appareil et du navigateur web.
Contenu connexe
- Découvrez comment intégrer AKS à Microsoft Entra ID dans l’article de procédure d’intégration de Microsoft Entra ID géré par AKS.
- Pour une prise en main des identités managées dans AKS, consultez Utiliser une identité managée dans AKS.
- Pour bien démarrer avec les identités de charge de travail dans AKS, consultez Utiliser une identité de charge de travail dans AKS.