Utiliser le contrôle d’accès en fonction du rôle Kubernetes avec Microsoft Entra ID dans Azure Kubernetes Service

Azure Kubernetes Service (AKS) peut être configuré pour utiliser Microsoft Entra ID pour une authentification utilisateur. Dans cette configuration, vous vous connectez à un cluster AKS à l’aide d’un jeton d’authentification Microsoft Entra. Une fois authentifié, vous pouvez utiliser le contrôle d’accès en fonction du rôle Kubernetes (Kubernetes RBAC) intégré pour gérer l’accès aux espaces de noms et aux ressources de cluster en fonction de l’identité d’un utilisateur ou de l’appartenance à un groupe.

Cet article vous montre comment :

• Contrôler l’accès à l’aide du contrôle d’accès en fonction du rôle (RBAC) Kubernetes dans un cluster AKS en fonction de l’appartenance au groupe Microsoft Entra.
• Créer des exemples de groupes et d’utilisateurs dans Microsoft Entra ID.
• Créez des rôles et des RoleBindings dans un cluster AKS afin d’accorder les autorisations appropriées pour créer et voir des ressources.

Avant de commencer

• Vous disposez d’un cluster AKS existant sur lequel l’intégration Microsoft Entra est activée. Si vous avez besoin d’un cluster AKS avec cette configuration, consultez Intégrer Microsoft Entra ID à AKS.
• Le RBAC Kubernetes est activé par défaut lors de la création du cluster AKS. Pour mettre à niveau votre cluster avec l’intégration Microsoft Entra et le contrôle d’accès en fonction du rôle (RBAC) Kubernetes, Activez l’intégration Microsoft Entra sur votre cluster AKS existant.
• Vérifiez qu’Azure CLI version 2.0.61 ou ultérieure est installé et configuré. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
• Si vous utilisez Terraform, installez Terraform version 2.99.0 ou ultérieure.

Utilisez le portail Azure ou Azure CLI pour vérifier si l’intégration Microsoft Entra avec le contrôle d’accès en fonction du rôle (RBAC) Kubernetes est activée.

Azure portal

Vérifier à l’aide du Portail Azure :

1. Connectez-vous au Portail Azure et accédez à votre ressource cluster AKS.
2. Dans le menu du service, sous Paramètres, sélectionnez Configuration du cluster.
3. Dans la section Authentification et autorisation, vérifiez si l’option Authentification Microsoft Entra avec le contrôle d’accès en fonction du rôle (RBAC) Kubernetes est sélectionnée.

Azure CLI

Vous pouvez vérifier à l’aide de la commande Azure CLI az aks show. Remplacez la valeur myResourceGroup par le nom du groupe de ressources hébergeant la ressource de cluster Azure Kubernetes Service (AKS) et remplacez myAKSCluster par le nom réel de votre cluster AKS.

az aks show --resource-group myResourceGroup --name myAKSCluster

S’il est activé, la sortie affiche la valeur false pour enableAzureRbac.

Créer des groupes de démonstration dans Microsoft Entra ID

Dans cet article, nous allons créer deux rôles utilisateurs pour montrer comment le contrôle d’accès en fonction du rôle (RBAC) Kubernetes et Microsoft Entra ID contrôlent l’accès aux ressources du cluster. Les deux exemples de rôles suivants sont utilisés :

• Développeur d’application
  • Utilisateur nommé aksdev faisant partie du groupe appdev.
• Ingénieur de fiabilité de site
  • Utilisateur nommé akssre faisant partie du groupe opssre.

Dans des environnements de production, vous pouvez utiliser des utilisateurs et groupes existants au sein d’un locataire Microsoft Entra.

1. Commencez par obtenir l’ID de ressource de votre cluster AKS à l’aide de la commande az aks show. Attribuez ensuite l’ID de ressource à une variable nommée AKS_ID pour pouvoir y faire référence dans d’autres commandes.

   AKS_ID=$(az aks show \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --query id -o tsv)
   

2. Créez le premier exemple de groupe dans Microsoft Entra ID pour les développeurs d’applications à l’aide de la commande az ad group create. L’exemple suivant crée un groupe nommé appdev :

   APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
   

3. Créez une attribution de rôle Azure pour le groupe appdev à l’aide de la commande az role assignment create. Cette attribution permet à tout membre du groupe d’utiliser kubectl pour interagir avec un cluster AKS en lui octroyant le Rôle utilisateur de cluster du service Azure Kubernetes.

   az role assignment create \
     --assignee $APPDEV_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

Conseil

Si vous recevez une erreur telle que Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5., attendez quelques secondes pour que l’ID d’objet de groupe Microsoft Entra se propage dans le répertoire, puis réexécutez la commande az role assignment create.

4. Créez un deuxième exemple de groupe pour les ingénieurs de fiabilité de site, nommé opssre.

   OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)
   

5. Créez une attribution de rôle Azure pour accorder aux membres du groupe le Rôle utilisateur de cluster du service Azure Kubernetes.

   az role assignment create \
     --assignee $OPSSRE_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

Créer des utilisateurs de démonstration dans Microsoft Entra ID

Avec les deux exemples de groupes créés dans Microsoft Entra ID pour nos développeurs d’applications et SRE, nous allons créer deux exemples d’utilisateurs. Pour tester l’intégration de Kubernetes RBAC à la fin de l’article, vous allez vous connecter au cluster AKS avec ces comptes.

Définir le nom d’utilisateur principal et le mot de passe pour les développeurs d’applications

Définissez le nom d’utilisateur principal (UPN) et le mot de passe des développeurs d’applications. L’UPN doit inclure le nom de domaine vérifié de votre locataire, par exemple, aksdev@contoso.com.

La commande suivante vous invite à entrer l’UPN et le définit sur AAD_DEV_UPN en vue de son utilisation dans une commande ultérieure :

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

La commande suivante vous invite à entrer le mot de passe et lui affecte la valeur AAD_DEV_PW pour une utilisation dans une commande ultérieure :

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

Créer les comptes d’utilisateur

1. Créez le premier compte d’utilisateur dans Microsoft Entra ID à l’aide de la commande az ad user create. L’exemple suivant crée un utilisateur avec le nom d’affichage AKS Dev, et l’UPN et un mot de passe sécurisé à l’aide des valeurs de AAD_DEV_UPN et AAD_DEV_PW :

AKSDEV_ID=$(az ad user create \
  --display-name "AKS Dev" \
  --user-principal-name $AAD_DEV_UPN \
  --password $AAD_DEV_PW \
  --query id -o tsv)

2. Ajoutez l’utilisateur au groupe appdev créé dans la section précédente à l’aide de la commande az ad group member add.

az ad group member add --group appdev --member-id $AKSDEV_ID

3. Définissez l’UPN et le mot de passe pour SREs. L’UPN doit inclure le nom de domaine vérifié de votre locataire, par exemple, akssre@contoso.com. La commande suivante vous invite à entrer l’UPN et lui affecte la valeur AAD_SRE_UPN pour une utilisation dans une commande ultérieure :

echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN

4. La commande suivante vous invite à entrer le mot de passe et lui affecte la valeur AAD_SRE_PW pour une utilisation dans une commande ultérieure :

echo "Please enter the secure password for SREs: " && read AAD_SRE_PW

5. Créez un deuxième compte d’utilisateur. L’exemple suivant crée un utilisateur avec le nom d’affichage AKS SRE, et l’UPN et un mot de passe sécurisé à l’aide des valeurs de AAD_SRE_UPN et AAD_SRE_PW :

# Create a user for the SRE role
AKSSRE_ID=$(az ad user create \
  --display-name "AKS SRE" \
  --user-principal-name $AAD_SRE_UPN \
  --password $AAD_SRE_PW \
  --query id -o tsv)

# Add the user to the opssre Azure AD group
az ad group member add --group opssre --member-id $AKSSRE_ID

Créer des ressources de cluster AKS pour les développeurs d’applications

Nous avons créé nos groupes et utilisateurs Microsoft Entra et nos attributions de rôle Azure. Maintenant, nous allons configurer le cluster AKS pour autoriser ces différents groupes à accéder à des ressources spécifiques.

1. Obtenez les informations d’identification de l’administrateur de cluster à l’aide de la commande az aks get-credentials. Dans l’une des sections 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 myAKSCluster --admin

2. Créez un espace de noms dans le cluster AKS à l’aide de la commande kubectl create namespace. L’exemple suivant crée un espace de noms nommé dev :

kubectl create namespace dev

Remarque

Dans Kubernetes, les Roles définissent les autorisations à accorder, et les RoleBindings les appliquent aux utilisateurs ou groupes 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.

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 (UPN). Si l’utilisateur se trouve dans un autre locataire Microsoft Entra, recherchez et utilisez plutôt la propriété objectId.

3. Créez un Role pour l’espace de noms dev, qui accorde des autorisations complètes à l’espace de noms. Dans des environnements de production, vous pouvez spécifier des autorisations plus granulaires pour différents utilisateurs ou groupes. Créez un fichier nommé role-dev-namespace.yaml et collez le manifeste YAML suivant :

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

4. Créez le Role à l’aide de la commande kubectl apply et spécifiez le nom de fichier de votre manifeste YAML.

kubectl apply -f role-dev-namespace.yaml

5. Obtenez l’ID de ressource du groupe appdev à l’aide de la commande az ad group show. Ce groupe est défini en tant qu’objet d’un RoleBinding à l’étape suivante.

az ad group show --group appdev --query id -o tsv

6. Créez un RoleBinding pour le groupe appdev afin d’utiliser le Role créé précédemment pour l’accès à l’espace de noms. Créez un fichier nommé rolebinding-dev-namespace.yaml et collez le manifeste YAML suivant. Sur la dernière ligne, remplacez groupObjectId par l’ID d’objet de groupe retourné par la commande précédente.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  namespace: dev
  name: groupObjectId

Conseil

Si vous souhaitez créer le RoleBinding pour un seul utilisateur, spécifiez genre : Utilisateur et remplacez groupObjectId par le nom d’utilisateur principal (UPN) dans l’exemple ci-dessus.

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

kubectl apply -f rolebinding-dev-namespace.yaml

Créer les ressources de cluster AKS pour les ingénieurs de fiabilité de site

Nous allons à présent répéter les étapes précédentes pour créer un espace de noms, un Role et un RoleBinding pour les ingénieurs de fiabilité de site.

1. Créez un espace de noms pour sre à l’aide de la commande kubectl create namespace.

kubectl create namespace sre

2. Créez un fichier nommé role-sre-namespace.yaml et collez le manifeste YAML suivant :

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

3. Créez le Role à l’aide de la commande kubectl apply et spécifiez le nom de fichier de votre manifeste YAML.

kubectl apply -f role-sre-namespace.yaml

4. Obtenez l’ID de ressource du groupe opssre à l’aide de la commande az ad group show.

az ad group show --group opssre --query id -o tsv

4. Créez un RoleBinding pour le groupe opssre afin d’utiliser le Role créé précédemment pour l’accès à l’espace de noms. Créez un fichier nommé rolebinding-sre-namespace.yaml et collez le manifeste YAML suivant. Sur la dernière ligne, remplacez groupObjectId par l’ID d’objet de groupe retourné par la commande précédente.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-access
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
- kind: Group
  namespace: sre
  name: groupObjectId

5. Créez le RoleBinding à l’aide de la commande kubectl apply et spécifiez le nom de fichier de votre manifeste YAML.

kubectl apply -f rolebinding-sre-namespace.yaml

Interagir avec des ressources de cluster à l’aide d’identités Microsoft Entra

Maintenant, nous allons tester que les autorisations attendues fonctionnent quand vous créez et gérez des ressources dans un cluster AKS. Dans ces exemples, nous allons planifier et afficher des pods dans l’espace de noms attribué de l’utilisateur et essayer de planifier et d’afficher des pods en dehors de l’espace de noms attribué.

1. Réinitialisez le contexte kubeconfig à l’aide de la commande az aks get-credentials. Dans une section précédente, vous avez défini le contexte en utilisant les informations d’identification d’administrateur de cluster. L’utilisateur administrateur contourne les invites de connexion Microsoft Entra. Sans le paramètre --admin, le contexte utilisateur appliqué requiert que toutes les requêtes soient authentifiées à l’aide de Microsoft Entra ID.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

2. Planifiez un pod NGINX de base à l’aide de la commande kubectl run dans l’espace de noms dev.

kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

3. Entrez les informations d’identification de votre propre compte appdev@contoso.com créé au début de l’article à l’invite de connexion. Quand vous êtes correctement connecté, le jeton de compte est mis en cache pour des commandes kubectl futures. Le pod NGINX est correctement planifié, comme le montre l’exemple de sortie suivant :

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

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

pod/nginx-dev created

4. Utilisez la commande kubectl get pods pour afficher tous les pods dans l’espace de noms dev.

kubectl get pods --namespace dev

5. Vérifiez que l’état du pod NGINX est En cours d’exécution. La sortie ressemble à ce qui suit :

$ kubectl get pods --namespace dev

NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

Créer et afficher des ressources de cluster en dehors de l’espace de noms attribué

Essayez d’afficher des pods en dehors de l’espace de noms dev. Utilisez de nouveau la commande kubectl get pods, cette fois pour voir --all-namespaces.

kubectl get pods --all-namespaces

L’appartenance de groupe de l’utilisateur n’a pas de Role Kubernetes autorisant cette action comme le montre l’exemple de sortie suivant :

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope

De la même façon, essayez de planifier un pod dans un espace de noms différent tel que sre. L’appartenance de groupe de l’utilisateur ne s’aligne pas avec un Role et un RoleBinding Kubernetes pour accorder ces autorisations comme le montre l’exemple de sortie suivant :

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

Tester l’accès d’ingénieur de fiabilité de site aux ressources de cluster AKS

Pour confirmer que notre appartenance au groupe Microsoft Entra et le contrôle d’accès en fonction du rôle (RBAC) Kubernetes fonctionnent correctement entre les différents utilisateurs et groupes, essayez les commandes précédentes lorsque vous êtes connecté en tant qu’utilisateur opssre.

1. Réinitialisez le contexte kubeconfig à l’aide de la commande az aks get-credentials, qui efface le jeton d’authentification précédemment mis en cache pour l’utilisateur aksdev.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

2. Essayez de planifier et d’afficher les pods dans l’espace de noms sre attribué. Quand vous y êtes invité, connectez-vous avec vos propres informations d’identification opssre@contoso.com créées au début de l’article.

kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
kubectl get pods --namespace sre

Comme le montre l’exemple de sortie suivant, vous pouvez correctement créer et afficher les pods :

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

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

pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0

4. Essayez d’afficher ou de planifier des pods en dehors de l’espace de noms SRE attribué.

kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

Ces commandes kubectl échouent, comme le montre l’exemple de sortie suivant. L’appartenance de groupe de l’utilisateur et le Role et les RoleBindings Kubernetes n’accordent pas d’autorisations pour créer ou gérer des ressources dans d’autres espaces de noms.

$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"

Nettoyer les ressources

Dans cet article, vous avez créé des ressources dans le cluster AKS, et des utilisateurs et groupes dans Microsoft Entra ID. Pour nettoyer toutes les ressources, exécutez les commandes suivantes :

# Get the admin kubeconfig context to delete the necessary cluster resources.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Azure AD user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

Étapes suivantes

• Pour plus d’informations sur la sécurisation des clusters Kubernetes, consultez Options d’accès et d’identité pour 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).