Utiliser l’autorisation d’ID Microsoft Entra pour l’API Kubernetes dans AKS

Cet article explique comment autoriser les appels à l’API Kubernetes dans Azure Kubernetes Service (AKS) à l’aide d’identités d’ID Microsoft Entra. L’autorisation Entra ID pour l’API Kubernetes utilise des attributions de rôles RBAC Azure pour accorder l’accès aux ressources Kubernetes. Pour les ressources Kubernetes intégrées, attribuez l’un des rôles intégrés AKS (tels que Azure Kubernetes Service RBAC Reader) à l'échelle du cluster ou 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 obtenir une vue d’ensemble conceptuelle des options d’autorisation d’API Kubernetes disponibles dans AKS, consultez les concepts d’autorisation du cluster.

Avant de commencer

• 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 de l’intégration de Microsoft Entra gérée activée sur votre cluster avant de pouvoir ajouter l’autorisation d’ID Entra 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 d’ID Entra pour l’API Kubernetes nécessite que le locataire Microsoft Entra configuré pour l’authentification soit identique au locataire de l’abonnement qui contient votre cluster AKS.

Créer un nouveau cluster AKS avec intégration Microsoft Entra gérée et autorisation Entra ID

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 avec l’intégration Microsoft Entra managée et l’autorisation 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 l’autorisation Entra ID sur un cluster AKS existant

• Activez l’autorisation d’ID Entra pour l’API Kubernetes sur un cluster AKS existant en utilisant la commande az aks update avec l’option --enable-azure-rbac.

  az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac
  

Rôles intégrés d'AKS

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

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

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, en remplaçant <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.

   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)

Les conditions ABAC vous permettent de filtrer les attributions de rôles Microsoft Entra ID vers des groupes et des types spécifiques de ressources personnalisées (CRD) — de manière centralisée, depuis Microsoft Entra ID, sans écrire de manifestes Kubernetes RBAC Role et RoleBinding par cluster. 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 :

Ajouter une condition ABAC à une attribution de rôle

L’exemple suivant crée un rôle personnalisé Lecteur CRD AKS qui accorde la lecture des ressources personnalisées, puis l’assigne avec une condition qui autorise uniquement l’accès secretproviderclasses au groupe secrets-store.csi.x-k8s.io (le CRD employé par le fournisseur Azure Key Vault pour le driver CSI du magasin de secrets).

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.

   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.

   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 du webhook d’autorisation Entra ID (en supposant que le CRD Istio est installé sur le cluster ; sinon, kubectl retourne une erreur « non trouvé » 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 Entra ID

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

  az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac
  

Supprimer l’attribution de rôle

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

Étapes suivantes

Pour en savoir plus sur l’authentification, l’autorisation AKS, kubernetes RBAC et Azure RBAC, consultez :

• 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