Contrôler l’accès à l’aide du RBAC Microsoft Entra ID et Kubernetes dans AKS activé par Azure Arc

  • Article

S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server

Azure Kubernetes Service (AKS) peut être configuré pour utiliser Microsoft Entra ID pour l’authentification utilisateur. Dans cette configuration, vous vous connectez à un cluster Kubernetes à 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 explique comment contrôler l’accès à l’aide du RBAC Kubernetes dans un cluster Kubernetes en fonction de Microsoft Entra’appartenance au groupe dans AKS Arc. Vous créez un groupe de démonstration et des utilisateurs dans Microsoft Entra ID. Ensuite, vous créez des rôles et des liaisons de rôles dans le cluster pour accorder les autorisations appropriées pour créer et afficher des ressources.

Prérequis

Avant de configurer le RBAC Kubernetes à l’aide de Microsoft Entra identité, vous avez besoin des éléments suivants :

  • Un cluster Kubernetes créé dans AKS Arc

    Vous avez besoin d’un cluster Kubernetes créé dans AKS Arc. Si vous devez configurer votre cluster, vous trouverez des instructions pour utiliser Windows Admin Center ou PowerShell pour déployer AKS.

  • Connexion Azure Arc

    Vous devez disposer d’une connexion Azure Arc à votre cluster Kubernetes. Pour plus d’informations sur l’activation d’Azure Arc, consultez Connecter un Azure Kubernetes Service sur un cluster Azure Stack HCI à Kubernetes avec Azure Arc.

  • Vous devez accéder aux outils en ligne de commande suivants :

    • Azure CLI et l’extension connectedk8s

      L’interface de ligne de commande Azure (Azure CLI) est un ensemble de commandes qui sert à créer et à gérer des ressources Azure. Pour case activée si vous disposez d’Azure CLI, ouvrez un outil en ligne de commande et tapez : az -v. En outre, vous devez installer l’extension connectedk8s pour ouvrir un canal sur votre cluster Kubernetes.

      Pour obtenir des instructions d’installation, consultez Installation de l’interface de ligne de commande Azure.

    • Kubectl

      L’outil en ligne de commande Kubernetes, kubectl, vous permet d’exécuter des commandes ciblant vos clusters Kubernetes. Pour case activée si vous avez installé kubectl, ouvrez un outil en ligne de commande et tapez : kubectl version --client. Assurez-vous que la version de votre client kubectl est au moins v1.24.0.

      Pour obtenir des instructions d’installation, consultez kubectl.

    • PowerShell et le module AksHci PowerShell

      PowerShell est une solution multiplateforme d’automatisation des tâches, composée d’un interpréteur de commandes (shell), d’un langage de script et d’un framework de gestion de la configuration. Si vous avez installé AKS Arc, vous avez accès au module PowerShell AksHci.

Étapes initiales facultatives

Si vous ne disposez pas déjà d’un groupe Microsoft Entra qui contient des membres, vous pouvez créer un groupe et ajouter des membres, afin de suivre les instructions de cet article.

Pour illustrer l’utilisation de Microsoft Entra ID et du RBAC Kubernetes, vous pouvez créer un groupe Microsoft Entra pour les développeurs d’applications qui peut être utilisé pour montrer comment le RBAC Kubernetes et Microsoft Entra ID contrôle l’accès aux ressources de cluster. Dans les environnements de production, vous pouvez utiliser des utilisateurs et des groupes existants au sein d’un locataire Microsoft Entra.

Créer un groupe de démonstration dans Microsoft Entra ID

Tout d’abord, créez le groupe dans Microsoft Entra ID dans votre locataire pour les développeurs d’applications à l’aide de la commande az ad group create. L’exemple suivant vous permet de vous connecter à votre locataire Azure, puis de créer un groupe nommé appdev :

az login
az ad group create --display-name appdev --mail-nickname appdev

Ajouter des utilisateurs à votre groupe

Avec l’exemple de groupe créé dans Microsoft Entra ID pour nos développeurs d’applications, nous allons ajouter un utilisateur au appdev groupe. Vous allez utiliser ce compte d’utilisateur pour vous connecter au cluster AKS et tester l’intégration RBAC Kubernetes.

Ajoutez l’utilisateur au groupe appdev créé dans la section précédente à l’aide de la commande az ad group member add. Si vous quittez votre session, reconnectez-vous à Azure à l’aide de az login.

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

Créer une liaison de rôle RBAC Kubernetes personnalisée sur la ressource de cluster AKS pour le groupe Microsoft Entra

Configurez le cluster AKS pour permettre à votre groupe Microsoft Entra d’accéder au cluster. Si vous souhaitez ajouter un groupe et des utilisateurs, consultez Créer des groupes de démonstration dans Microsoft Entra ID.

  1. Obtenez les informations d’identification de l’administrateur de cluster à l’aide de la commande Get-AksHciCredential :

    Get-AksHciCredential -name <name-of-your-cluster>

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

    kubectl create namespace dev

    Dans Kubernetes, les Roles définissent les autorisations à accorder, et les RoleBindings les appliquent aux utilisateurs ou groupes souhaités. Ces affectations peuvent être appliquées à un espace de noms donné ou à l’ensemble d’un cluster. Pour plus d’informations, consultez Utilisation de l’autorisation Kubernetes RBAC.

    Créez un rôle pour l’espace de noms de développement . Ce rôle accorde des autorisations complètes pour l’espace de noms. Dans les environnements de production, vous pouvez spécifier des autorisations plus granulaires pour différents utilisateurs ou groupes.

  3. 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 rôle à 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 comme objet d’un RoleBinding à l’étape suivante :

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

    La az ad group show commande retourne la valeur que vous allez utiliser comme groupObjectId:

    38E5FA30-XXXX-4895-9A00-050712E3673A

  6. Créez un fichier nommé rolebinding-dev-namespace.yaml, puis collez le manifeste YAML suivant. Vous établissez la liaison de rôle qui permet au groupe appdev d’utiliser le rôle pour l’accès à l’espace role-dev-namespace de noms. Sur la dernière ligne, remplacez groupObjectId par l’ID d’objet de groupe généré par la az ad group show commande.

    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 kind: User et remplacez groupObjectId par le nom d’utilisateur principal (UPN) dans l’exemple.

  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

    rolebinding.rbac.authorization.k8s.io/dev-user-access created

Utiliser des rôles RBAC Kubernetes intégrés pour votre ressource de cluster AKS

Kubernetes fournit également des rôles intégrés pour les utilisateurs. Ces rôles intégrés comprennent :

  • Les rôles super-utilisateurs (cluster-admin)
  • Les rôles destinés à être accordés à l’échelle du cluster à l’aide de ClusterRoleBindings
  • Les rôles destinés à être accordés dans des espaces de noms particuliers à l’aide de RoleBindings (administration, modification, affichage)

Pour en savoir plus sur les rôles RBAC Kubernetes intégrés, consultez Rôles kubernetes RBAC orientés utilisateur

Rôles pour les utilisateurs

ClusterRole par défaut ClusterRoleBinding par défaut Description
cluster-admin Groupe system:masters Autorise l’accès super-utilisateur pour effectuer n’importe quelle action sur n’importe quelle ressource. Lorsqu’il est utilisé dans un ClusterRoleBinding, ce rôle donne un contrôle total sur chaque ressource du cluster et dans tous les espaces de noms. Lorsqu’il est utilisé dans un RoleBinding, il offre un contrôle total sur chaque ressource dans l’espace de noms de la liaison de rôle, y compris l’espace de noms lui-même.
admin None Autorise l’accès administrateur, destiné à être accordé dans un espace de noms à l’aide d’une liaison de rôle. Si elle est utilisée dans une liaison de rôle, autorise l’accès en lecture/écriture à la plupart des ressources d’un espace de noms, 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. Ce rôle n’autorise pas non plus l’accès en écriture aux points de terminaison dans les clusters créés à l’aide de Kubernetes v1.22+. Pour plus d’informations, consultez Accès en écriture pour les points de terminaison.
modifier None 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 permet d’accéder aux secrets et d’exécuter des pods comme n’importe quel ServiceAccount dans l’espace de noms. Il peut donc être utilisé pour obtenir les niveaux d’accès d’API de n’importe quel ServiceAccount dans l’espace de noms. Ce rôle n’autorise pas non plus l’accès en écriture aux points de terminaison dans les clusters créés à l’aide de Kubernetes v1.22+. Pour plus d’informations, consultez Accès en écriture pour les points de terminaison.
vue None 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 des secrets, car la lecture du contenu des secrets permet d’accéder aux informations d’identification ServiceAccount dans l’espace de noms, ce qui autoriserait l’accès à l’API en tant que serviceAccount dans l’espace de noms (une forme d’escalade des privilèges).

Utiliser un rôle RBAC Kubernetes intégré avec Microsoft Entra ID

Pour utiliser un rôle RBAC Kubernetes intégré avec Microsoft Entra ID, procédez comme suit :

  1. Appliquez le rôle RBAC Kubernetes intégré view à votre groupe Microsoft Entra :

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>

  2. Appliquez le rôle RBAC Kubernetes intégré view à chacun de vos utilisateurs Microsoft Entra :

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>

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

À présent, testez les autorisations attendues lorsque vous créez et gérez des ressources dans un cluster Kubernetes. Dans ces exemples, vous allez planifier et afficher des pods dans l’espace de noms attribué de l’utilisateur. Ensuite, vous essayez de planifier et d’afficher les pods en dehors de l’espace de noms attribué.

  1. Connectez-vous à Azure à l’aide du $AKSDEV_ID compte d’utilisateur que vous avez passé en tant qu’entrée à la az ad group member add commande. Exécutez la az connectedk8s proxy commande pour ouvrir un canal sur le cluster :

    az connectedk8s proxy -n <cluster-name> -g <resource-group>

  2. Une fois le canal proxy établi, ouvrez une autre session et planifiez un pod NGINX à 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

    Lorsque NGINX a été correctement planifié, vous voyez la sortie suivante :

    pod/nginx-dev created

  3. À présent, utilisez la commande kubectl get pods pour afficher les pods dans l’espace de dev noms :

    kubectl get pods --namespace dev

    Lorsque NGINX s’exécute correctement, la sortie suivante s’affiche :

    $ 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é

Pour tenter d’afficher des pods en dehors de l’espace de noms dev , utilisez la commande kubectl get pods avec l’indicateur --all-namespaces .

kubectl get pods --all-namespaces

L’appartenance au groupe de l’utilisateur n’a pas de rôle Kubernetes qui autorise cette action. Sans l’autorisation, la commande génère une erreur.

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

Étapes suivantes