Utiliser kubelogin pour authentifier les utilisateurs dans Azure Kubernetes Service (AKS)

Le plug-in kubelogin dans Azure est un plug-in d’identification pour client-go qui implémente l’authentification Microsoft Entra. Le plug-in kubelogin propose des fonctionnalités non disponibles dans l’outil en ligne de commande kubectl. Pour plus d’informations, consultez l’introduction à kubelogin et l’introduction à kubectl.

Cet article fournit une vue d’ensemble et des exemples d’utilisation de kubelogin pour les méthodes d’authentification Microsoft Entra prises en charge recommandées pour AKS.

Limitations de l'authentification Kubelogin dans AKS

  • Les groupes créés dans Microsoft Entra sont inclus uniquement par leur valeur ObjectID , et non par leur nom complet. La commande sAMAccountName n’est disponible que pour les groupes synchronisés depuis un Windows Server Active Directory local.
  • La méthode d’authentification du principal de service fonctionne uniquement avec l’intégration de Microsoft Entra ID managée, pas avec l’intégration Microsoft Entra ID héritée.
  • Un service principal peut être membre d’un maximum de 200 groupes Microsoft Entra. Si vous avez plus de 200 groupes, il est recommandé d’utiliser des rôles d’application.
  • La méthode d’authentification par code d’appareil ne fonctionne pas lorsqu’une stratégie d’accès conditionnel Microsoft Entra est configurée sur le locataire Microsoft Entra. Dans ce scénario, utilisez plutôt l’authentification interactive du navigateur web.
  • La méthode d’authentification Azure CLI fonctionne uniquement avec Microsoft Entra.

Fonctionnement de l’authentification kubelogin dans AKS

Les clusters AKS exécutant Kubernetes version 1.24 ou ultérieure utilisent automatiquement le format du plug-in kubelogin exec. Les clusters exécutant des versions kubernetes antérieures à la version 1.24 nécessitent une conversion manuelle vers ce format.

Pour la plupart des interactions avec kubelogin, utilisez la convert-kubeconfig sous-commande. La sous-commande utilise le fichier kubeconfig que vous spécifiez 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 correspondent aux flux d’octroi de jeton OAuth 2.0 de Microsoft Entra. Le comportement du cache dépend de la méthode d’authentification. Les enregistrements d’authentification pour le code d’appareil, l’authentification interactive via le navigateur web et l’authentification par informations d’identification de mot de passe du propriétaire de la ressource (ROPC) sont mis en cache dans le répertoire de cache de kubelogin. Les méthodes telles que Azure CLI et Azure Developer CLI utilisent le cache géré par leur outil en ligne de commande respectif au lieu du cache kubelogin.

Authentification de code d’appareil

Le code d’appareil est la méthode d’authentification par défaut pour la sous-commande convert-kubeconfig. Cette méthode invite l’utilisateur à saisir le code d’appareil afin de se connecter via une session de navigateur.

Remarque

Avant l’introduction des plugins kubelogin et exec, la méthode d’authentification Azure dans kubectl ne prenait en charge que le flux de code d’appareil. Elle utilisait une version antérieure d’une bibliothèque qui générait un jeton dont la revendication audience comportait le préfixe spn:. Ce flux n’est pas compatible avec Microsoft Entra, qui utilise un flux OBO (on-behalf-of). Lors de l’exécution de la sous-commande convert-kubeconfig, kubelogin supprime le préfixe spn: de la revendication audience.

Paramètres pour l’authentification par code d’appareil

Le tableau suivant présente les paramètres que vous pouvez utiliser avec l’authentification du code d’appareil :

Paramètre Descriptif
-l devicecode (facultatif) Spécifie la méthode d’authentification kubelogin. Ce paramètre est facultatif, car le code de l’appareil est la méthode par défaut.
--legacy Utilise l’ancien comportement pour les clusters configurés avec l’intégration héritée de Microsoft Entra ID. Si le fichier kubeconfig concerne un tel cluster, kubelogin ajoute automatiquement l’indicateur --legacy .
--cache-dir Remplace le chemin d’accès par défaut du répertoire du cache de jetons, qui est ${HOME}/.kube/cache/kubelogin.

L'authentification de l'Azure CLI

La méthode d’authentification Azure CLI (commande : -l azurecli) 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 celui utilisé par az login. kubelogin n’écrit pas de jetons dans le fichier de cache de jetons, car Azure CLI les gère déjà.

Paramètres pour l’authentification Azure CLI

Le tableau suivant présente les paramètres que vous pouvez utiliser avec l’authentification Azure CLI :

Paramètre Descriptif
-l azurecli Spécifie la méthode d’authentification kubelogin.
--azure-config-dir Spécifie le répertoire de configuration Azure CLI. Le répertoire par défaut est ${HOME}/.azure.

Connexion à Azure

Connectez-vous à Azure à l’aide de la az login commande.

az login

Authentification interactive du navigateur web

La méthode d’authentification interactive du navigateur web (commande : -l interactive) 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.

Vous pouvez utiliser un jeton porteur ou un jeton de preuve de possession (PoP) avec cette méthode d’authentification.

Paramètres pour l’authentification par jeton du porteur

Le tableau suivant présente les paramètres que vous pouvez utiliser avec l’authentification par jeton du porteur :

Paramètre Descriptif
-l interactive Spécifie la méthode d’authentification kubelogin.
--cache-dir Remplace le chemin d’accès par défaut du répertoire du cache de jetons, qui est ${HOME}/.kube/cache/kubelogin.

Paramètres pour l’authentification par jeton PoP

Le tableau suivant présente les paramètres que vous pouvez utiliser avec l’authentification par jeton PoP :

Paramètre Descriptif
-l interactive Spécifie la méthode d’authentification kubelogin.
--pop-enabled Active l’authentification par jeton PoP.
--pop-claims Spécifie les attributs du jeton PoP dans un format de paire clé-valeur. Par exemple : u=/ARM/ID/OF/CLUSTER.

Authentification d’un principal du service

La méthode d’authentification du principal de service (commande : -l spn) utilise un principal de service pour authentifier l'utilisateur. Vous pouvez fournir les informations d’identification en définissant une variable d’environnement ou en utilisant les informations d’identification directement dans un argument de ligne de commande. Les types d’informations d’identification pris en charge sont un mot de passe ou un certificat client au format PFX (Personal Information Exchange).

Paramètres de l’authentification par service principal

Le tableau suivant présente les paramètres que vous pouvez utiliser avec l’authentification du principal de service :

Paramètre Descriptif
-l spn Spécifie la méthode d’authentification kubelogin.
--client-id ID d’application (id client) du principal de service.
--client-secret Secret client du principal de service.

Authentification d’une identité managée

Utilisez la méthode d’authentification d’identité managée (commande : -l msi) pour les applications qui se connectent aux ressources qui prennent en charge l’authentification Microsoft Entra. Par exemple, l’accès à des ressources Azure comme une machine virtuelle Azure, Virtual Machine Scale Sets ou Azure Cloud Shell.

Vous pouvez utiliser l’identité managée par défaut affectée à la ressource ou une identité managée affectée par l’utilisateur spécifique.

Paramètres pour l’authentification d’identité managée

Le tableau suivant présente les paramètres que vous pouvez utiliser avec l’authentification d’identité managée :

Paramètre Descriptif
-l msi Spécifie la méthode d’authentification kubelogin.
--client-id ID d’application (id client) de l’identité managée affectée par l’utilisateur. Si vous ne spécifiez pas ce paramètre, l’identité managée par défaut est utilisée.

Authentification par identité de charge de travail

La méthode d’authentification d’identité de charge de travail (commande : -l workloadidentity) utilise des informations d’identification d’identité fédérées avec Microsoft Entra pour authentifier l’accès aux clusters AKS. Cette méthode repose sur l’authentification intégrée Microsoft Entra. Elle fonctionne en configurant les variables d’environnement suivantes :

Variable Descriptif
AZURE_CLIENT_ID L’ID de l’application Microsoft Entra fédérée avec l’identité de charge de travail.
AZURE_TENANT_ID ID de locataire Microsoft Entra.
AZURE_FEDERATED_TOKEN_FILE Le fichier contenant une assertion signée de la charge de travail, comme un jeton JWT de compte de service projeté Kubernetes.
AZURE_AUTHORITY_HOST URL de base d'une instance 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 Argo CD sans stocker les informations d’identification du principal de service dans les systèmes externes. Pour configurer la fédération OpenID Connect (OIDC) depuis GitHub, consultez l’exemple de fédération OIDC.

Paramètres pour l’authentification par identité de charge de travail

Le tableau suivant présente les paramètres que vous pouvez utiliser avec l’authentification d’identité de charge de travail :

Paramètre Descriptif
-l workloadidentity Spécifie la méthode d’authentification kubelogin.

Authentification d’Azure Developer CLI

La méthode d’authentification d’Azure Developer CLI (commande : -l azd) utilise le contexte de connexion établi par Azure Developer CLI pour obtenir le jeton d’accès. Le jeton est émis dans le même locataire Microsoft Entra que celui utilisé par azd auth login. kubelogin n'écrit pas de jetons dans son cache de jetons, car l'interface CLI du développeur Azure les gère.

Cette méthode d’authentification fonctionne uniquement avec des Microsoft Entra managées dans AKS. Pour plus d’informations, consultez la vue d’ensemble de l’interface CLI Azure développeur.

Authentification des Azure Pipelines

La méthode d'authentification Azure Pipelines (commande : -l azurepipelines) utilise une connexion de service Azure Resource Manager et le jeton d'accès système du pipeline pour s'authentifier. Cette méthode fonctionne uniquement dans Azure Pipelines. Le pipeline doit disposer d’une connexion de service Azure Resource Manager et autoriser les scripts à accéder au jeton OAuth.

Lorsque vous utilisez une AzureCLI@2 tâche avec une connexion de service Azure Resource Manager, kubelogin peut utiliser l’ID de locataire, l’ID client et l’ID de connexion de service que Azure Pipelines fournit en tant que variables d’environnement. Pour plus d’informations, consultez les connexions de service Azure Pipelines.

Warning

kubelogin prend également en charge la méthode d’authentification ROPC (Resource Owner Password Credential). Microsoft recommande de ne pas utiliser ROPC, car il n'est pas compatible avec l'authentification multifacteur et certains scénarios d'identité hybride. Pour plus d’informations, consultez les recommandations Plateforme d'identités Microsoft relatives à ROPC.

Exporter le chemin du fichier kubeconfig

Avant d’exécuter la convert-kubeconfig sous-commande, exportez le chemin du fichier kubeconfig vers la variable d’environnement KUBECONFIG . Par exemple:

export KUBECONFIG=/path/to/kubeconfig

Convertir le fichier kubeconfig

Exécutez la convert-kubeconfig sous-commande pour convertir le fichier kubeconfig afin d’utiliser le plug-in exec pour votre méthode d’authentification choisie.

kubelogin convert-kubeconfig

kubelogin convert-kubeconfig -l azurecli

# Bearer token authentication
kubelogin convert-kubeconfig -l interactive

# Proof-of-Possession (PoP) token authentication
kubelogin convert-kubeconfig -l interactive --pop-enabled --pop-claims "u=/ARM/ID/OF/CLUSTER"

  1. Exécutez la convert-kubeconfig sous-commande pour convertir le fichier kubeconfig pour utiliser le plug-in exec.

    kubelogin convert-kubeconfig -l spn

  2. Définissez les variables d’environnement pour l’ID client et la clé secrète client ou le certificat client. Par exemple:

    export AZURE_CLIENT_ID=<service-principal-client-id>
export AZURE_CLIENT_SECRET=<service-principal-client-secret>

# Default managed identity authentication
kubelogin convert-kubeconfig -l msi

# Specific managed identity authentication
kubelogin convert-kubeconfig -l msi --client-id <managed-identity-client-id>

kubelogin convert-kubeconfig -l workloadidentity

Convertir le fichier kubeconfig à l’aide de l’interface CLI Azure Développeur

  1. Connectez-vous à l’aide de l’interface CLI Azure développeur.

    azd auth login

  2. Convertissez le fichier kubeconfig pour utiliser la méthode d’authentification CLI Azure développeur.

    kubelogin convert-kubeconfig -l azd

Convertir le fichier kubeconfig dans Azure Pipelines

Dans une tâche qui utilise une AzureCLI@2 connexion de service Azure Resource Manager, convertissez le fichier kubeconfig pour utiliser l’authentification Azure Pipelines.

kubelogin convert-kubeconfig -l azurepipelines

Supprimer des jetons mis en cache

Supprimez les jetons mis en cache à l’aide de la kubelogin remove-cache-dir commande.

kubelogin remove-cache-dir

Obtenir des informations sur les nœuds

Obtenez des informations sur le nœud à l’aide de la kubectl get commande.

kubectl get nodes

Comment utiliser des ID d’application kubelogin avec AKS

AKS utilise une paire d’applications Microsoft Entra propriétaires. Ces ID d’application sont identiques dans tous les environnements.

Application ID d’application (GUID) Utilisé dans
Application serveur AKS (--server-id) 6dae42f8-4368-4678-94ff-3960e28e3630 Audience du jeton pour toutes les méthodes d’authentification kubelogin prises en charge lors de l’accès à AKS.
Application cliente publique AKS (--client-id) 80faf920-1908-4b52-b5ef-a8e7bedfc67a Code de l’appareil, navigateur web interactif et authentification ROPC.

Lorsque vous appelez kubelogin get-token directement pour AKS, spécifiez l’ID d’application serveur AKS avec --server-id. Pour connaître les paramètres spécifiques au mode, consultez la référence kubeloginget-token.

Remarque

L’ID d’application cliente publique AKS dans cette section correspond à la valeur --client-id pour l’authentification par code d’appareil, par navigateur web interactif et ROPC. Pour l’authentification du principal de service et de l’identité managée, --client-id identifie plutôt le principal de service ou l’identité managée affectée par l’utilisateur.

Par exemple, obtenez un jeton à l’aide de l’authentification du code d’appareil et des ID d’application AKS :

kubelogin get-token \
    --login devicecode \
    --server-id 6dae42f8-4368-4678-94ff-3960e28e3630 \
    --client-id 80faf920-1908-4b52-b5ef-a8e7bedfc67a \
    --tenant-id <microsoft-entra-tenant-id>

Contenu connexe

  • Dernière mise à jour :