Partager via

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 pour l’utilisation 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. Pour plus d'informations, consultez l'introduction à kubelogin et l'introduction à 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 tous les méthodes d’authentification Microsoft Entra prises en charge dans AKS.

Limites

  • Vous pouvez inclure un maximum de 200 groupes dans une revendication JSON Web Token (JWT) Microsoft Entra. Si vous avez plus de 200 groupes, utilisez 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 d’affichage. La commande sAMAccountName 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 Microsoft Entra ID managé, et non avec la version antérieure Azure Active Directory.
  • La méthode d’authentification par code d’appareil ne fonctionne pas lorsqu’une stratégie d’Accès conditionnel Microsoft Entra est définie sur un tenant 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 sous-commande convert-kubeconfig. La sous-commande utilise le fichier kubeconfig spécifié dans --kubeconfig ou dans la variable d’environnement KUBECONFIG 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 OAuth 2.0 Microsoft Entra. Les indicateurs de paramètre suivants sont couramment utilisés 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 tenant 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) (identité du workflow) 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 leur utilisation :

  • 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 d’appareil est la méthode d’authentification par défaut dans la sous-commande convert-kubeconfig. Le paramètre -l devicecode est facultatif. Cette méthode d’authentification invite l’utilisateur à entrer le code d’appareil pour 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 prenait en charge que le flux du code d’appareil. Une version antérieure d’une bibliothèque était utilisée pour produire un jeton qui possède la revendication audience avec un préfixe spn:. Cela n’est pas compatible avec Microsoft Entra ID managé par AKS, qui utilise un flux OBO (on-behalf-of). Lorsque vous exécutez la sous-commande convert-kubeconfig, kubelogin supprime le préfixe spn: de la revendication d’audience.

Si vos besoins incluent l’utilisation des fonctionnalités des versions antérieures, ajoutez l’argument --legacy. Si vous utilisez le fichier kubeconfig dans un cluster Azure Active Directory de version antérieure, kubelogin ajoute automatiquement l’indicateur de --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 d’accès, incluez le paramètre --token-cache-dir.

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 nettoyer les jetons mis en cache, exécutez la commande suivante :

kubelogin remove-tokens

Remarque

La méthode de connexion par code d’appareil ne fonctionne pas lorsqu’une stratégie d’accès conditionnel est configurée sur un tenant Microsoft Entra. Dans ce scénario, utilisez la méthode interactive de navigateur web.

Azure CLI

La méthode d’authentification Azure CLI utilise le contexte connecté établi par l’interface de ligne de commande Azure afin d’obtenir le jeton d’accès. Le jeton est émis dans le même tenant 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 l’interface Azure CLI.

Remarque

Cette méthode d’authentification fonctionne uniquement avec le service Microsoft Entra ID managé 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 paramètre --azure-config-dir avec la sous-commande convert-kubeconfig. La commande génère le fichier kubeconfig avec la variable d’environnement configurée. Vous pouvez obtenir la même configuration en paramétrant la variable d’environnement AZURE_CONFIG_DIR à ce répertoire au moment de l’exécution de la commande kubectl.

Navigateur web interactif

La méthode interactive du navigateur web d’authentification ouvre automatiquement un navigateur web pour permettre à l’utilisateur de se connecter. 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 d’accès à l’aide du paramètre --token-cache-dir.

Jeton du porteur

L’exemple suivant montre comment utiliser un jeton du porteur avec un 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 un 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 la connexion de 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 d’échange d’informations personnelles (PFX).

Avant d’utiliser cette méthode, tenez compte des limitations suivantes :

  • Cette méthode fonctionne uniquement avec Microsoft Entra ID managé.
  • Le principal de service peut être un 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 une clé secrète 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 obtenue à 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é managée

Utilisez la méthode d’authentification par 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. Elle 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 tenant 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 Connect (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 interactives par code d’appareil et via le navigateur web.

Contenu connexe