Contrôler l’accès à l’aide de l’ID Microsoft Entra et du RBAC Kubernetes

Article
07/30/2024

S’applique à : AKS sur Azure Stack HCI 23H2

Vous pouvez configurer Azure Kubernetes Service (AKS) pour utiliser l’ID Microsoft Entra 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 basé sur l’appartenance au groupe Microsoft Entra dans AKS. 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ôle dans le cluster pour accorder les autorisations appropriées pour créer et afficher des ressources.

Prérequis

Avant de configurer Kubernetes RBAC à l’aide de l’ID Microsoft Entra, vous devez disposer des conditions préalables suivantes :

AkS activé par un cluster Azure Arc. Si vous devez configurer votre cluster, consultez les instructions d’utilisation de la Portail Azure ou d’Azure CLI.
Azure CLI installé et configuré. Si vous avez besoin d’installer l’interface CLI ou la mise à niveau, consultez Installer Azure CLI.
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 vérifier si vous disposez d’Azure CLI, ouvrez un outil de ligne de commande et tapez : az -v. Installez également 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 qui ciblent vos clusters Kubernetes. Pour vérifier 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.
Vous pouvez accéder à votre cluster Kubernetes avec les autorisations spécifiées avec le mode direct ou le mode proxy.
- Pour accéder directement au cluster Kubernetes à l’aide de la az aksarc get-credentials commande, vous avez besoin des autorisations de rôle utilisateur du cluster Microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action, qui est incluse dans les autorisations de rôle d’utilisateur du cluster Azure Kubernetes Service Arc
- Pour accéder au cluster Kubernetes à partir de n’importe où avec un mode proxy à l’aide az connectedk8s proxy d’une commande, vous avez besoin de l’autorisation de rôle utilisateur du cluster Kubernetes Microsoft.Kubernetes/connectedClusterS/listClusterUserCredential/action, qui est incluse dans l’autorisation de rôle d’utilisateur du cluster Kubernetes avec Azure Arc. Pendant ce temps, vous devez vérifier que les agents et la machine qui effectuent le processus d’intégration répondent aux exigences réseau requises dans les exigences réseau Kubernetes compatibles avec Azure Arc.

Étapes initiales facultatives

Si vous n’avez pas encore de groupe Microsoft Entra qui contient des membres, vous pouvez créer un groupe et ajouter des membres afin de pouvoir suivre les instructions de cet article.

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

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

Tout d’abord, créez le groupe dans l’ID Microsoft Entra dans votre locataire pour les développeurs d’applications à l’aide de la az ad group create commande. L’exemple suivant vous invite à vous connecter à votre locataire Azure, puis crée 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 l’ID Microsoft Entra pour les développeurs d’applications, ajoutez un utilisateur au appdev groupe. Vous utilisez ce compte d’utilisateur pour vous connecter au cluster AKS et tester l’intégration RBAC Kubernetes.

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

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

Utilisez la az aksarc get-credentials commande pour obtenir les informations d’identification de l’administrateur de cluster :
```
az aksarc get-credentials --name "$aks_cluster_name" --resource-group "$resource_group_name" --admin
```
Créez un espace de noms dans le cluster Kubernetes à l’aide de la kubectl create namespace commande. 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 sur 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.

Créez un fichier nommé role-dev-namespace.yaml et copiez/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: ["*"]

Créez le rôle à l’aide de la kubectl apply commande et spécifiez le nom de fichier de votre manifeste YAML :
```
kubectl apply -f role-dev-namespace.yaml
```
Obtenez l’ID de ressource du groupe appdev à l’aide de la commande az ad group show. Ce groupe est défini comme sujet 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 utilisez comme groupObjectIdsuit :
```
38E5FA30-XXXX-4895-9A00-050712E3673A
```
Créez un fichier nommé rolebinding-dev-namespace.yaml, puis copiez/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 de l’objet du groupe produit par la commande az ad group show :
```
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 roleBinding pour un seul utilisateur, spécifiez et remplacez kind: User groupObjectId par le nom d’utilisateur principal (UPN) dans l’exemple.
Créez roleBinding à l’aide de la kubectl apply commande 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 plus d’informations sur les rôles RBAC Kubernetes intégrés, consultez rôles RBAC Kubernetes.

Rôles pour les utilisateurs

ClusterRole par défaut	ClusterRoleBinding par défaut	Description
cluster-admin	Groupe system:masters	Permet à un super-utilisateur d’accéder à 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	Aucune	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.
edit	Aucune	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 aux pods en cours d’exécution en tant que 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.
view	Aucune	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 (forme d’escalade de privilèges).

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

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

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>

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>

Accéder au cluster Kubernetes

Vous pouvez désormais accéder à votre cluster Kubernetes avec les autorisations spécifiées, à l’aide du mode direct ou du mode proxy.

Accéder à votre cluster avec kubectl (mode direct)

Pour accéder au cluster Kubernetes avec les autorisations spécifiées, l’opérateur Kubernetes a besoin de Microsoft Entra kubeconfig, que vous pouvez obtenir à l’aide de la az aksarc get-credentials commande. Cette commande permet d’accéder au kubeconfig basé sur l’administrateur, ainsi qu’à un kubeconfig basé sur l’utilisateur. Le fichier kubeconfig basé sur l’administrateur contient des secrets et doit être stocké en toute sécurité et pivoté régulièrement. En revanche, l’ID Microsoft Entra basé sur l’utilisateur kubeconfig ne contient pas de secrets et peut être distribué aux utilisateurs qui se connectent à partir de leurs ordinateurs clients.

Pour exécuter cette commande Azure CLI, vous avez besoin de Microsoft.HybridContainerService /provisionedClusterInstances/listUserKubeconfig/action, qui est inclus dans les autorisations de rôle utilisateur du cluster Azure Kubernetes Service Arc :

az aksarc get-credentials -g $resource_group_name -n $aks_cluster_name --file <file-name>

À présent, vous pouvez utiliser kubectl pour gérer votre cluster. Par exemple, vous pouvez répertorier les nœuds de votre cluster à l’aide de kubectl get nodes. La première fois que vous l’exécutez, vous devez vous connecter, comme illustré dans l’exemple suivant :

kubectl get nodes

Accéder à votre cluster à partir d’un appareil client (mode proxy)

Pour accéder au cluster Kubernetes à partir de n’importe où avec un mode proxy à l’aide az connectedk8s proxy de la commande, vous avez besoin de l’autorisation de rôle utilisateur du cluster Kubernetes avec Microsoft.Kubernetes/connectedClusterS/listClusterUserCredential/action, qui est incluse dans l’autorisation de rôle d’utilisateur du cluster Kubernetes avec Azure Arc.

Exécutez les étapes suivantes sur un autre appareil client :

Connectez-vous à l’aide de l’authentification Microsoft Entra.
Obtenez la connexion kubeconfig au cluster nécessaire pour communiquer avec le cluster n’importe où (depuis même en dehors du pare-feu entourant le cluster) :
```
az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name
```
Remarque

Cette commande ouvre le proxy et bloque l’interpréteur de commandes actuel.
Dans une autre session d’interpréteur de commandes, utilisez kubectl pour envoyer des requêtes au cluster :
```
kubectl get pods -A
```

Vous devez voir une réponse du cluster contenant la liste de tous les pods présents dans l’espace de noms default.

Pour plus d’informations, consultez Accéder à votre cluster à partir d’un appareil client

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

Pour tenter d’afficher des pods en dehors de l’espace de noms de développement , utilisez la kubectl get pods commande 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

Contrôle d’accès en fonction du rôle Azure (Azure RBAC)

Partager via