Utiliser kubelogin pour authentifier les utilisateurs dans Azure Kubernetes Service

  • Article

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