Intégrer Microsoft Entra ID à Azure Kubernetes Service (AKS) à l’aide d’Azure CLI (hérité)

Article
08/02/2024

Avertissement

La fonctionnalité décrite dans ce document, Intégration Microsoft Entra (héritée), est déconseillée depuis le 1er juin 2023. À ce stade, aucun nouveau cluster ne peut être créé avec la fonction Intégration Microsoft Entra (héritée).

AKS propose une nouvelle expérience Microsoft Entra ID gérée par AKS améliorée qui ne nécessite pas que vous gériez le serveur ou l’application cliente. Si vous souhaitez effectuer une migration, suivez les instructions ici.

Azure Kubernetes Service (AKS) peut être configuré pour utiliser Microsoft Entra ID pour une authentification utilisateur. Dans cette configuration, vous pouvez vous connecter à un cluster AKS à l’aide d’un jeton d’authentification Microsoft Entra. Les opérateurs de cluster peuvent également configurer le contrôle d’accès en fonction du rôle Kubernetes (Kubernetes RBAC) basé sur une identité utilisateur ou l’appartenance à un groupe de répertoires.

Cet article explique comment créer les composants Microsoft Entra requis, puis déployer un cluster compatible Microsoft Entra ID et créer un rôle Kubernetes de base dans le cluster AKS.

Limites

Microsoft Entra ID peut uniquement être activé sur un cluster sur lequel Kubernetes RBAC est activé.
L’intégration héritée de Microsoft Entra ne peut être activée que lors de la création du cluster.

Avant de commencer

L’interface de ligne de commande Azure (Azure CLI) version 2.0.61 ou une version ultérieure doit avoir été installée et configurée. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Accédez à https://shell.azure.com pour ouvrir Cloud Shell dans votre navigateur.

Par souci de cohérence et pour faciliter l’exécution des commandes décrites dans cet article, créez une variable pour votre nom de cluster AKS souhaité. L’exemple suivant utilise le nom myakscluster :

aksname="myakscluster"

Vue d’ensemble de l’authentification Microsoft Entra

L’authentification Microsoft Entra est fournie aux clusters AKS à l’aide d’OpenID Connect. OpenID Connect est une couche d’identité basée sur le protocole OAuth 2.0. Pour plus d’informations sur OpenID Connect, consultez la Documentation sur OpenID Connect.

Depuis le cluster Kubernetes, l’authentification par jeton de Webhook est utilisée pour vérifier les jetons d’authentification. L’authentification par jeton de Webhook est configurée et gérée en tant que partie du cluster AKS. Pour plus d’informations sur l’authentification par jeton Webhook, voir la documentation sur l’authentification de webhook.

Remarque

Lors de la configuration de Microsoft Entra ID pour l’authentification AKS, deux applications Microsoft Entra sont configurées. Cette opération doit être effectuée par un administrateur de locataire Azure.

Créer un composant serveur Microsoft Entra

Pour intégrer avec AKS, vous créez et utilisez une application Microsoft Entra qui agit en tant que point de terminaison pour les demandes d’identité. La première application Microsoft Entra dont vous avez besoin obtient l’appartenance au groupe Microsoft Entra pour un utilisateur.

Créez le composant d’application serveur avec la commande az ad app create, puis mettez à jour les revendications d’appartenance au groupe avec la commande az ad app update. L’exemple suivant utilise la variable aksname définie dans la section Avant de commencer et crée une variable

# Create the Azure AD application
serverApplicationId=$(az ad app create \
    --display-name "${aksname}Server" \
    --identifier-uris "https://${aksname}Server" \
    --query appId -o tsv)

# Update the application group membership claims
az ad app update --id $serverApplicationId --set groupMembershipClaims=All

Maintenant, créez un principal de service pour l’application serveur avec la commande az ad sp create. Ce principal de service est utilisé pour s’authentifier dans la plateforme Azure. Ensuite, obtenez le secret du principal de service en utilisant la commande az ad sp credential reset et affectez-le à la variable nommée serverApplicationSecret pour l’utiliser dans l’une des étapes suivantes :

# Create a service principal for the Azure AD application
az ad sp create --id $serverApplicationId

# Get the service principal secret
serverApplicationSecret=$(az ad sp credential reset \
    --name $serverApplicationId \
    --credential-description "AKSPassword" \
    --query password -o tsv)

Le principal de service Microsoft Entra a besoin d’autorisations pour effectuer les actions suivantes :

Lire les données du répertoire
Connecter et lire le profil utilisateur

Attribuez ces autorisations à l’aide de la commande az ad app permission add :

az ad app permission add \
    --id $serverApplicationId \
    --api 00000003-0000-0000-c000-000000000000 \
    --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope 06da0dbc-49e2-44d2-8312-53f166ab848a=Scope 7ab1d382-f21e-4acd-a863-ba3e13f7da61=Role

Enfin, accordez les autorisations attribuées dans l’étape précédente pour l’application serveur à l’aide de la commande az ad app permission grant. Cette étape échoue si le compte actuel n’est pas un administrateur de locataire. Vous devez également ajouter des autorisations pour que l’application Microsoft Entra demande des informations, qui sinon pourraient nécessiter le consentement de l’administrateur avec az ad app permission admin-consent :

az ad app permission grant --id $serverApplicationId --api 00000003-0000-0000-c000-000000000000
az ad app permission admin-consent --id  $serverApplicationId

Créer un composant client Microsoft Entra

La deuxième application Microsoft Entra est utilisée quand un utilisateur se connecte au cluster AKS avec l’interface de ligne de commande Kubernetes (kubectl). Cette application cliente prend la demande d’authentification de l’utilisateur et vérifie les informations d’identification et les autorisations. Créez l’application Microsoft Entra pour le composant de client à l’aide de la commande az ad app create :

clientApplicationId=$(az ad app create \
    --display-name "${aksname}Client" \
    --native-app \
    --reply-urls "https://${aksname}Client" \
    --query appId -o tsv)

Créez un principal de service pour l’application cliente à l’aide de la commande az ad sp create :

az ad sp create --id $clientApplicationId

Obtenez l’ID oAuth2 pour l’application serveur afin de permettre le flux d’authentification entre les deux composants d’application à l’aide de la commande az ad app show. Cet ID oAuth2 sera utilisé dans l’étape suivante.

oAuthPermissionId=$(az ad app show --id $serverApplicationId --query "oauth2Permissions[0].id" -o tsv)

Ajoutez les autorisations pour les composants d’application cliente et d’application serveur nécessaires pour utiliser le flux de communication oAuth2 à l’aide de la commande az ad app permission add. Ensuite, accordez des autorisations pour que l’application cliente communique avec l’application serveur en utilisant la commande az ad app permission grant :

az ad app permission add --id $clientApplicationId --api $serverApplicationId --api-permissions ${oAuthPermissionId}=Scope
az ad app permission grant --id $clientApplicationId --api $serverApplicationId

Déployer le cluster

Les deux applications Microsoft Entra étant créées, vous pouvez créer à présent le cluster AKS. Commencez par créer un groupe de ressources à l’aide de la commande az group create. L’exemple suivant crée le groupe de ressources dans la région EastUS :

Créez un groupe de ressources pour le cluster :

az group create --name myResourceGroup --location EastUS

Obtenez l’ID de locataire de votre abonnement Azure à l’aide de la commande az account show. Ensuite, créez le cluster AKS avec la commande az aks create. La commande pour créer le cluster AKS fournit les ID d’application serveur et cliente, le secret du principal de service de l’application serveur et votre ID de locataire :

tenantId=$(az account show --query tenantId -o tsv)

az aks create \
    --resource-group myResourceGroup \
    --name $aksname \
    --node-count 1 \
    --generate-ssh-keys \
    --aad-server-app-id $serverApplicationId \
    --aad-server-app-secret $serverApplicationSecret \
    --aad-client-app-id $clientApplicationId \
    --aad-tenant-id $tenantId

Enfin, obtenez les informations d’identification d’administrateur du cluster à l’aide de la commande az aks get-credentials. Dans l’une des étapes suivantes, vous obtenez les informations d’identification de cluster utilisateur ordinaires pour voir le flux d’authentification Microsoft Entra en action.

az aks get-credentials --resource-group myResourceGroup --name $aksname --admin

Créer une liaison Kubernetes RBAC

Avant de pouvoir utiliser un compte Microsoft Entra avec le cluster AKS, une liaison de rôle ou une liaison de rôle de cluster doit être créée. Les rôlesdéfinissent les permissions à accorder, et les liaisonsles appliquent aux utilisateurs souhaités. Ces affectations peuvent s’appliquer à un espace de noms donné ou à l’ensemble du cluster. Pour plus d’informations, consultez Utilisation de l’autorisation Kubernetes RBAC.

Obtenez le nom d’utilisateur principal (UPN) de l’utilisateur actuellement connecté à l’aide de la commande az ad signed-in-user show. Ce compte d’utilisateur est activé pour l’intégration de Microsoft Entra à l’étape suivante.

az ad signed-in-user show --query userPrincipalName -o tsv

Important

Si l’utilisateur auquel vous octroyez la liaison de contrôle d’accès en fonction du rôle (RBAC) Kubernetes figure dans le même locataire Microsoft Entra, attribuez les autorisations en fonction du userPrincipalName. Si l’utilisateur se trouve dans un autre locataire Microsoft Entra, recherchez et utilisez plutôt la propriété objectId.

Créez un manifeste YAML nommé basic-azure-ad-binding.yaml, et collez le contenu suivant. Sur la dernière ligne, remplacez userPrincipalName_or_objectId par l’UPN ou l’ID d’objet retournés par la commande précédente :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: contoso-cluster-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: userPrincipalName_or_objectId

Créez la ClusterRoleBinding à l’aide de la commande kubectl apply, et spécifiez le nom de fichier de votre manifeste YAML :

kubectl apply -f basic-azure-ad-binding.yaml

Accéder au cluster avec Microsoft Entra ID

Testons à présent l’intégration de l’authentification Microsoft Entra pour le cluster AKS. Définissez le contexte de configuration kubectl pour utiliser les informations d’identification d’un utilisateur standard. Ce contexte réachemine toutes les demandes d’authentification via Microsoft Entra ID.

az aks get-credentials --resource-group myResourceGroup --name $aksname --overwrite-existing

Utilisez à présent la commande kubectl get pods pour afficher les pods dans tous les espaces de noms :

kubectl get pods --all-namespaces

Vous recevez une invite de connexion vous demandant de vous authentifier en entrant vos informations d’identification Microsoft Entra dans un navigateur web. Une fois que vous êtes authentifié, la commande kubectl affiche les pods figurant dans le cluster AKS, comme illustré dans l’exemple de sortie suivant :

kubectl get pods --all-namespaces

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BYMK7UXVD to authenticate.

NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE
kube-system   coredns-754f947b4-2v75r                 1/1     Running   0          23h
kube-system   coredns-754f947b4-tghwh                 1/1     Running   0          23h
kube-system   coredns-autoscaler-6fcdb7d64-4wkvp      1/1     Running   0          23h
kube-system   heapster-5fb7488d97-t5wzk               2/2     Running   0          23h
kube-system   kube-proxy-2nd5m                        1/1     Running   0          23h
kube-system   kube-svc-redirect-swp9r                 2/2     Running   0          23h
kube-system   kubernetes-dashboard-847bb4ddc6-trt7m   1/1     Running   0          23h
kube-system   metrics-server-7b97f9cd9-btxzz          1/1     Running   0          23h
kube-system   tunnelfront-6ff887cffb-xkfmq            1/1     Running   0          23h

Le jeton d’authentification reçu pour kubectl est mis en cache. Vous n’êtes réinvité à vous connecter que quand le jeton a expiré ou lorsque le fichier de configuration Kubernetes est recréé.

Si vous voyez un message d’erreur d’autorisation s’afficher après que vous vous êtes connecté avec succès à l’aide d’un navigateur web, comme dans l’exemple de sortie ci-après, vérifiez les problèmes possibles suivants :

error: You must be logged in to the server (Unauthorized)

Vous avez défini l’ID d’objet ou l’UPN approprié, en fonction du fait que le compte utilisateur se trouve ou non dans le même locataire Microsoft Entra.
L'utilisateur n’est pas membre de plus de 200 groupes.
Le secret défini dans l’inscription d’application pour le serveur correspond à la valeur configurée à l’aide de --aad-server-app-secret
Assurez-vous qu’une seule version de kubectl est installée sur votre ordinateur à la fois. Les versions conflictuelles peuvent entraîner des problèmes lors de l’autorisation. Pour installer la dernière version, utilisez az aks install-cli.

Forum aux questions sur la migration de Microsoft Entra Integration vers Microsoft Entra ID géré par AKS

1. Quel est le plan de migration ?

L’intégration Microsoft Entra (hérité) sera déconseillé le 1er juin 2023. Après cette date, vous ne pourrez pas créer de clusters avec Microsoft Entra ID (hérité). Nous allons migrer tous les clusters AKS de l’intégration Microsoft Entra (hérité) vers Microsoft Entra géré par AKS à partir du 1er août 2023. Nous envoyons des e-mails de notification aux administrateurs d’abonnement concernés deux fois par semaine pour leur rappeler la migration.

2. Que se passe-t-il si je ne fais rien ?

Vos clusters AKS de l’intégration Microsoft Entra (hérité) continueront de fonctionner après le 1er juin 2023. Nous allons migrer automatiquement vos clusters vers Microsoft Entra ID géré par AKS à partir du 1er août 2023. Il se peut que vous éprouviez des temps d’arrêt du serveur d’API pendant la migration.

Le contenu kubeconfig change après la migration. Vous devez fusionner les nouvelles informations d’identification dans le fichier kubeconfig à l’aide de az aks get-credentials --resource-group <AKS resource group name> --name <AKS cluster name>.

Nous vous recommandons de mettre à jour votre cluster AKS vers Microsoft Entra ID géré par AKS manuellement avant le 1er août. Vous pouvez ainsi gérer les temps d’arrêt en dehors des heures d’ouverture lorsque c’est plus pratique.

3. Pourquoi je reçois quand même l’e-mail de notification après la migration manuelle ?

L’envoi de l’e-mail prend plusieurs jours. Il se peut que vous receviez une notification si votre cluster n’a pas été migré avant le début du processus d’envoi des e-mails.

4. Comment puis-je vérifier si mon cluster est migré vers Microsoft Entra ID géré par AKS ?

Vérifiez que votre cluster AKS est migré vers Microsoft Entra ID géré par AKS à l’aide de la commande az aks show.

az aks show -g <RGName> -n <ClusterName>  --query "aadProfile"

Si votre cluster utilise Microsoft Entra ID géré par AKS, la sortie managed s’affiche true. Par exemple :

    {
      "adminGroupObjectIDs": [
        "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      ],
      "adminUsers": null,
      "clientAppId": null,
      "enableAzureRbac": null,
      "managed": true,
      "serverAppId": null,
      "serverAppSecret": null,
      "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }

Étapes suivantes

Pour obtenir le script complet contenant les commandes présentées dans cet article, consultez le [script d’intégration Microsoft Entra dans le référentiel d’exemples AKS][complete-script].

Pour utiliser des utilisateurs et des groupes Microsoft Entra pour le contrôle d’accès à des ressources de cluster, consultez Contrôler l’accès aux ressources de cluster à l’aide du contrôle d’accès en fonction du rôle Kubernetes et d’identités Microsoft Entra dans AKS.

Pour plus d’informations sur la sécurisation des clusters Kubernetes, consultez Options d’accès et d’identité pour Azure Kubernetes Service (AKS).

Pour découvrir les meilleures pratiques de contrôle des identités et des ressources, consultez Meilleurs pratiques relatives à l’authentification et à l’autorisation dans Azure Kubernetes Service (AKS).

Partager via