Partager via

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

  • 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 une 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 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ô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 avez besoin des prérequis suivants :

  • Un cluster Kubernetes créé dans AKS Arc. Si vous devez configurer votre cluster, consultez les instructions d’utilisation de Windows Admin Center ou de 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 cluster Azure Kubernetes Service sur Azure Stack HCI à Kubernetes avec Azure Arc.
  • Vous avez besoin d’accéder aux outils en ligne de commande suivants :
    • Azure CLI et l’extension connectedk8s. Azure CLI est un ensemble de commandes utilisées pour 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 Comment installer Azure CLI.
    • Kubectl. Cet outil en ligne de commande Kubernetes vous permet d’exécuter des commandes ciblant vos clusters Kubernetes. Pour vérifier si vous avez installé kubectl, ouvrez une invite de commandes et tapez : kubectl version --client. Vérifiez que votre version du client kubectl est au moins la version v1.24.0. Pour obtenir des instructions d’installation, consultez kubectl.
    • PowerShell et le module PowerShell AksHci. PowerShell est une solution d’automatisation des tâches multiplateforme composée d’un interpréteur de commandes, d’un langage de script et d’une infrastructure de gestion de la configuration. Si vous avez installé AKS Arc, vous avez accès au module PowerShell AksHci .
    • 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. 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.

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

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

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

  3. 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: ["*"]

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

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

  6. 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 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 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 :

  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 des ID 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 des pods en dehors de l’espace de noms affecté.

  1. Connectez-vous à Azure à l’aide du $AKSDEV_ID compte d’utilisateur que vous avez spécifié comme entrée dans la az ad group member add commande. Exécutez la az connectedk8s proxy commande pour ouvrir un canal vers 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 kubectl run commande dans l’espace de noms de développement :

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

    Lorsque NGINX est correctement planifié, vous devez voir la sortie suivante :

    pod/nginx-dev created

  3. Utilisez maintenant la kubectl get pods commande pour afficher les pods dans l’espace dev de noms :

    kubectl get pods --namespace dev

    Une fois NGINX en cours d’exécution, la sortie suivante doit s’afficher :

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