Utilisez Microsoft Entra ID autorisation pour l’API Kubernetes dans Azure Kubernetes Service (AKS)

S’applique à : ✔️ AKS Automatic ✔️ AKS Standard

Cet article explique comment autoriser les appels à l’API Kubernetes dans Azure Kubernetes Service (AKS) à l’aide de Microsoft Entra ID identités. L’autorisation Microsoft Entra ID pour l’API Kubernetes utilise les attributions de rôles Azure RBAC pour accorder l’accès aux ressources Kubernetes. Pour les ressources Kubernetes intégrées, affectez l’un des rôles intégrés AKS (tels que Azure Kubernetes Service lecteur RBAC) au niveau du cluster ou de l’étendue de l’espace de noms. Pour les ressources personnalisées (CRD), attribuez un rôle personnalisé avec des conditions Azure ABAC qui spécifient les groupes CRD ou types auxquels le bénéficiaire peut accéder. Les deux attributions de rôles composent : l’une accorde l’accès aux ressources Kubernetes standard, et l’autre accorde un accès conditionnel à des ressources personnalisées spécifiques.

Pour la plupart des charges de travail de production, AKS Automatic est l’option par défaut recommandée pour un environnement de production sur AKS. Les clusters automatiques AKS sont préconfigurés avec Azure RBAC pour l’autorisation Kubernetes. Vous pouvez donc vous concentrer sur l’affectation des attributions de rôles Microsoft Entra appropriées aux utilisateurs, groupes et principaux de service.

Pour obtenir une vue d’ensemble conceptuelle des options d’autorisation d’API Kubernetes disponibles dans AKS, consultez les concepts d’autorisation du cluster.

Note

Lorsque vous utilisez l’authentification intégrée entre l’ID Microsoft Entra et AKS, vous pouvez utiliser des utilisateurs, des groupes ou des principaux de service Microsoft Entra en tant que sujets dans le contrôle d’accès en fonction du rôle Kubernetes (RBAC Kubernetes). En utilisant Microsoft Entra ID autorisation, vous n'avez pas besoin de gérer séparément les identités utilisateur et les informations d'identification pour Kubernetes. Toutefois, vous devez toujours configurer et gérer Microsoft Entra ID attributions de rôles et toutes les liaisons RBAC Kubernetes séparément.

Note

Les clusters automatiques AKS sont préconfigurés pour utiliser Azure RBAC pour l’autorisation Kubernetes. Vous n’avez pas besoin d’activer --enable-azure-rbac sur les clusters automatiques AKS. Dans AKS Standard, vous pouvez activer ou désactiver Azure RBAC en fonction de la configuration de votre cluster.

Prerequisites

• Vous avez besoin d’Azure CLI version 2.24.0 ou ultérieure installée et configurée. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
• Vous avez besoin de kubectl, avec une version minimale de 1.18.3.
• Vous avez besoin d’une intégration de Microsoft Entra managée activée sur votre cluster avant de pouvoir ajouter Microsoft Entra ID autorisation pour l’API Kubernetes. Si vous devez activer l’intégration de Microsoft Entra managée, consultez Utiliser l’ID Microsoft Entra dans AKS.
• Les nouvelles attributions de rôles peuvent prendre jusqu’à cinq minutes pour se propager et être mises à jour par le serveur d’autorisation.
• L’autorisation Microsoft Entra ID pour l’API Kubernetes requiert que le locataire Microsoft Entra configuré pour l’authentification soit le même que celui de l’abonnement dans lequel se trouve votre cluster AKS.

Comportement du mode cluster AKS

Mode de cluster	Azure RBAC pour l’autorisation Kubernetes
AKS Automatic	Préconfiguré (activé par défaut)
AKS Standard	Facultatif (activer avec --enable-azure-rbac)

Créer un cluster AKS avec intégration Microsoft Entra managée et autorisation de Microsoft Entra ID

AKS Automatic (recommandé pour les charges de travail de production)

Pour les nouvelles charges de travail de production, utilisez AKS Automatic. Le système RBAC Azure pour l’autorisation Kubernetes est préconfiguré sur les clusters AKS Automatic.

1. Créez un cluster automatique AKS en suivant Créer un cluster automatique Azure Kubernetes Service (AKS).

2. Facultatif : vérifiez que Azure RBAC pour l’autorisation Kubernetes est activé sur votre cluster à l’aide de la az aks show commande.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   az aks show \
     --resource-group $RESOURCE_GROUP \
     --name $CLUSTER_NAME \
     --query "aadProfile.enableAzureRbac" \
     --output tsv
   

AKS Standard

1. Créez un groupe de ressources Azure à l’aide de la commande az group create.

   export RESOURCE_GROUP=<resource-group-name>
   export LOCATION=<azure-region>
   
   az group create --name $RESOURCE_GROUP --location $LOCATION
   

2. Créez un cluster AKS Standard avec intégration managée à Microsoft Entra et autorisation Microsoft Entra ID à l’aide de la commande az aks create.

   export CLUSTER_NAME=<cluster-name>
   
   az aks create \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --enable-aad \
       --enable-azure-rbac \
       --generate-ssh-keys
   

   Vous devez obtenir un résultat semblable à l’exemple de sortie qui suit :

   "AADProfile": {
       "adminGroupObjectIds": null,
       "clientAppId": null,
       "enableAzureRbac": true,
       "managed": true,
       "serverAppId": null,
       "serverAppSecret": null,
       "tenantId": "****-****-****-****-****"
   }
   

Activer Microsoft Entra ID autorisation sur un cluster AKS existant

Pour les clusters AKS Standard existants, activez l’autorisation Microsoft Entra ID pour l’API Kubernetes à l’aide de la commande az aks update avec l’indicateur --enable-azure-rbac.

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<cluster-name>

# Enable Microsoft Entra ID authorization for the Kubernetes API
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac

Les clusters automatiques AKS ont déjà Azure RBAC pour l’autorisation Kubernetes préconfigurée. Vous n’avez pas besoin d’exécuter --enable-azure-rbac pour AKS Automatic.

Rôles intégrés d'AKS

AKS fournit les rôles intégrés suivants :

Rôle	Description
Lecteur RBAC d'Azure Kubernetes Service	Autorise l’accès en lecture seule pour voir la plupart des objets dans un espace de noms. Ce rôle n’autorise pas l’affichage des rôles et des liaisons de rôles. Ce rôle n’autorise pas l’affichage Secrets, car la lecture du contenu des secrets permet d’accéder aux informations d’identification des comptes de service dans l’espace de noms, ce qui permettrait à n'importe quel compte de service d’accéder à l’API dans cet espace de noms (une forme d’escalade de privilèges).
Rédacteur RBAC Azure Kubernetes Service	Autorise l’accès en lecture/écriture pour la plupart des objets dans un espace de noms. Ce rôle n’autorise pas l’affichage ni la modification des rôles et des liaisons de rôles. Toutefois, ce rôle autorise l’accès Secrets et l’exécution de Pods en tant que ServiceAccount dans l’espace de noms, afin qu’il puisse être utilisé pour obtenir les niveaux d’accès d’API de n’importe quel ServiceAccount dans l’espace de noms.
Administrateur RBAC du service Azure Kubernetes	Autorise l’accès administrateur, normalement accordé au sein d’un espace de noms. Autorise l’accès en lecture/écriture à la plupart des ressources dans un espace de noms (ou dans l’étendue du cluster), y compris la possibilité de créer des rôles et des liaisons de rôles dans l’espace de noms. Ce rôle n’autorise pas l’accès en écriture au quota de ressources ou à l’espace de noms lui-même.
Administrateur du cluster RBAC Azure Kubernetes Service	Autorise l’accès de super utilisateur qui permet d’effectuer n’importe quelle action sur toutes les ressources. Il offre un contrôle total sur chaque ressource du cluster et dans tous les espaces de noms.

Créer des attributions de rôles pour l’accès au cluster

Service de contrôle d’accès Azure (CLI)

1. Obtenez votre ID de ressource AKS à l’aide de la az aks show commande.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   

2. Créez une affectation de rôle à l’aide de la commande az role assignment create. <AAD-ENTITY-ID> peut être un nom d’utilisateur ou l’ID client d’un principal de service. L’exemple suivant crée une attribution de rôle pour le rôle d’administrateur RBAC Azure Kubernetes Service.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   
   # Create a role assignment for the Azure Kubernetes Service RBAC Admin role
   az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
   

   Note

   Vous pouvez créer les attributions de rôle Azure Kubernetes Service RBAC Reader et Azure Kubernetes Service RBAC Writer, limitées à un espace de noms spécifique dans le cluster, à l’aide de la commande az role assignment create et en définissant l’étendue sur l’espace de noms souhaité.

   az role assignment create --role "Azure Kubernetes Service RBAC Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID/namespaces/<namespace-name>
   

portail Azure

1. Dans le portail Azure, accédez à votre cluster AKS.

2. Dans le menu du service, sélectionnez Contrôle d’accès (IAM)>Ajouter une attribution de rôle.

3. Sous l’onglet Rôle, sélectionnez le rôle souhaité, par exemple Azure Kubernetes Service Administrateur RBAC, puis sélectionnez Suivant.

4. Sous l’onglet Membres , configurez les paramètres suivants :

   • Attribuer l’accès à : sélectionnez Utilisateur, groupe ou principal du service.
   • Membres : Sélectionnez + Sélectionner des membres, recherchez et sélectionnez les membres souhaités, puis sélectionnez Sélectionner.

5. Sélectionnez Réviser + affecter>Affecter.

   Note

   Dans le portail Azure, après avoir créé des attributions de rôles avec une portée limitée à un espace de noms donné, vous ne pouvez pas afficher les attributions de rôles pour l’espace de noms à une étendue donnée. Vous pouvez les trouver à l’aide de la az role assignment list commande, ou répertorier les attributions de rôles pour un utilisateur ou un groupe auquel vous avez affecté le rôle.

   az role assignment list --scope $AKS_ID/namespaces/<namespace-name>
   

Créer des définitions de rôles personnalisés

Pour les ressources Kubernetes intégrées, les définitions de rôle personnalisées référencent l’action de groupe d’API correspondante sous Microsoft.ContainerService/managedClusters/. L’exemple suivant permet à un utilisateur de lire uniquement les déploiements et rien d’autre. Pour obtenir la liste complète des actions possibles, consultez les opérations Microsoft.ContainerService. Pour filtrer l’accès à des groupes ou types de ressources personnalisées spécifiques, consultez Restreindre l’accès aux ressources personnalisées à l’aide de conditions ABAC plus loin dans cet article.

1. Pour créer vos propres définitions de rôle personnalisées, copiez le fichier suivant, remplacez-le <YOUR-SUBSCRIPTION-ID> par votre propre ID d’abonnement, puis enregistrez-le sous deploy-view.json.

   {
       "Name": "AKS Deployment Reader",
       "Description": "Lets you view all deployments in cluster/namespace.",
       "Actions": [],
       "NotActions": [],
       "DataActions": [
           "Microsoft.ContainerService/managedClusters/apps/deployments/read"
       ],
       "NotDataActions": [],
       "assignableScopes": [
           "/subscriptions/<YOUR-SUBSCRIPTION-ID>"
       ]
   }
   

2. Créez la définition de rôle à l’aide de la commande az role definition create, en définissant --role-definition sur le fichier deploy-view.json que vous avez créé à l’étape précédente.

   az role definition create --role-definition @deploy-view.json 
   

3. Affectez la définition de rôle à un utilisateur ou à une autre identité à l’aide de la az role assignment create commande.

       # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   
   # Create a role assignment for the AKS Deployment Reader role
   az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
   

Restreindre l'accès aux ressources personnalisées à l'aide de conditions ABAC (aperçu)

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions d'essai sont fournies « en l’état » et « selon disponibilité », et elles sont exclues des contrats de niveau de service et de la garantie limitée. Les versions préliminaires AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

• Stratégies de support AKS
• FAQ du support Azure

Les conditions ABAC vous permettent de filtrer les attributions de rôles Microsoft Entra ID par groupes et types de ressources personnalisées (CRD) spécifiques, de façon centralisée, depuis Microsoft Entra ID, sans avoir à rédiger, pour chaque cluster, des manifestes Kubernetes RBAC Role et RoleBinding. Pour plus d’informations sur Azure ABAC, consultez Quelles sont les conditions d’attribution de rôle Azure ?

Quand utiliser des conditions ABAC

Utilisez cette fonctionnalité lorsque vous souhaitez :

• Limitez les groupes CRD ou types qu’un assigneur peut répertorier ou obtenir.
• Appliquer centralement les limites d'accès aux ressources définies par l'utilisateur depuis l'ID Microsoft Entra sans gérer les objets RBAC Role et RoleBinding Kubernetes sur chaque cluster.
• Faire la distinction entre les CRD publiés par différents opérateurs (par exemple, autoriser secrets-store.csi.x-k8s.io lors du blocage security.istio.io).

Attributs de condition disponibles

Les attributs de requête suivants sont disponibles lors de la création de conditions pour l’API Kubernetes sur un cluster AKS :

Caractéristique	Description
Microsoft.ContainerService/managedClusters/customResources:group	Groupe d’API de la ressource personnalisée accessible (par exemple). secrets-store.csi.x-k8s.io
Microsoft.ContainerService/managedClusters/customResources:kind	Type de la ressource personnalisée accessible (par exemple, secretproviderclasses).

Ajouter une condition ABAC à une attribution de rôle

L’exemple suivant crée un rôle personnalisé lecteur CRD AKS qui accorde l’accès en lecture aux ressources personnalisées. Ensuite, il assigne le rôle avec une condition qui n’autorise l’accès qu’à secretproviderclasses dans le groupe secrets-store.csi.x-k8s.io (le CRD utilisé par le fournisseur Azure Key Vault du pilote CSI Secrets Store).

1. Enregistrez la définition de rôle suivante dans un fichier nommé crd-reader.json, en remplaçant <YOUR-SUBSCRIPTION-ID> par votre propre ID d’abonnement.

   {
       "Name": "AKS CRD Reader",
       "Description": "Lets you read custom resources in the cluster.",
       "Actions": [],
       "NotActions": [],
       "DataActions": [
           "Microsoft.ContainerService/managedClusters/customresources/read"
       ],
       "NotDataActions": [],
       "assignableScopes": [
           "/subscriptions/<YOUR-SUBSCRIPTION-ID>"
       ]
   }
   

2. Créez la définition de rôle à l’aide de la az role definition create commande.

   az role definition create --role-definition @crd-reader.json
   

3. Enregistrez la condition suivante dans un fichier nommé abac-condition.txt. La condition permet aux lectures de ressources non personnalisées de se faire sans modification, et restreint les lectures de ressources personnalisées à un groupe et un genre spécifiques.

   (
    (
     !(ActionMatches{'Microsoft.ContainerService/managedClusters/customresources/read'})
    )
    OR
    (
     @Request[Microsoft.ContainerService/managedClusters/customResources:group] StringEqualsIgnoreCase 'secrets-store.csi.x-k8s.io'
     AND
     @Request[Microsoft.ContainerService/managedClusters/customResources:kind] StringEqualsIgnoreCase 'secretproviderclasses'
    )
   )
   

4. Créez l’attribution de rôle avec la condition à l’aide de la commande az role assignment create.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   
   # Create a role assignment for the AKS CRD Reader role with an ABAC condition
   az role assignment create \
       --role "AKS CRD Reader" \
       --assignee <AAD-ENTITY-ID> \
       --scope $AKS_ID \
       --condition "$(cat abac-condition.txt)" \
       --condition-version "2.0" \
       --description "Allow reads on SecretProviderClass resources only"
   

Vous pouvez également ajouter une condition via le portail Azure. Dans la page Ajouter une attribution de rôle , sélectionnez l’onglet Conditions , puis sélectionnez Ajouter une condition et utilisez l’éditeur visuel pour générer l’expression.

Vérifier la condition

Après la propagation de l’attribution de rôle (jusqu’à cinq minutes), connectez-vous en tant que bénéficiaire et vérifiez qu’il peut lire le CRD autorisé, mais pas les autres CRD.

1. Obtenez les informations d’identification du cluster à l’aide de la az aks get-credentials commande.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the cluster credentials
   az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
   

2. Liste secretproviderclasses du groupe secrets-store.csi.x-k8s.io, que la condition autorise. La commande doit réussir et retourner les ressources existantes ou une liste vide (ou une erreur introuvable si le CRD n’est pas installé sur le cluster).

   kubectl get secretproviderclasses.secrets-store.csi.x-k8s.io --all-namespaces
   

3. Liste authorizationpolicies du groupe Istio security.istio.io que la condition bloque. La commande doit échouer avec une erreur Forbidden provenant du webhook d’autorisation Microsoft Entra ID (en supposant que le CRD Istio est installé sur le cluster ; sinon kubectl retourne une erreur indiquant que la ressource est introuvable avant que le serveur API n’atteigne le webhook d’autorisation).

   kubectl get authorizationpolicies.security.istio.io --all-namespaces
   

Nettoyer les ressources

Désactiver l’autorisation Microsoft Entra ID

Supprimez l’autorisation Microsoft Entra ID à l’aide de la commande az aks update avec l’indicateur --disable-azure-rbac.

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<cluster-name>

# Disable Microsoft Entra ID authorization for the Kubernetes API
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac

Supprimer l’attribution de rôle

Service de contrôle d’accès Azure (CLI)

1. Répertorier les attributions de rôles à l’aide de la az role assignment list commande.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   
   # List role assignments for the AKS cluster
   az role assignment list --scope $AKS_ID --query [].id --output tsv
   

2. Supprimez les attributions de rôles à l’aide de la az role assignment delete commande.

   az role assignment delete --ids <LIST OF ASSIGNMENT IDS>
   

portail Azure

1. Accédez à votre cluster AKS et sélectionnez Attributions de rôles>
2. Sélectionnez l’attribution de rôle à supprimer, puis sélectionnez Supprimer>oui.

Supprimer une définition de rôle

Supprimez une définition de rôle personnalisée à l’aide de la az role definition delete commande.

az role definition delete --name "AKS Deployment Reader"

Supprimer un groupe de ressources et un cluster AKS

Service de contrôle d’accès Azure (CLI)

Supprimez le groupe de ressources (et le cluster AKS qu’il contient) à l’aide de la az group delete commande.

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>

# Delete the resource group and all resources in it
az group delete --name $RESOURCE_GROUP --yes --no-wait

portail Azure

1. Accédez au groupe de ressources qui contient votre cluster AKS, puis sélectionnez Supprimer le groupe de ressources.
2. Dans Supprimer un groupe de ressources, entrez le nom du groupe de ressources, puis sélectionnez Supprimer>.

Contenu connexe

Pour en savoir plus sur AKS, consultez les articles suivants :

• Qu’est-ce qu’AKS Automatic ?
• Créer un cluster automatique AKS
• Concepts d’autorisation de cluster pour AKS
• options d’accès et d’identité pour AKS
• Qu’est-ce qu’Azure RBAC ?
• Quelles sont les conditions Azure ABAC ?
• Opérations Microsoft.ContainerService