Partager via

Utilisez Privileged Identity Management (PIM) pour contrôler l’accès à vos clusters et nœuds Azure Kubernetes Service (AKS)

Lorsque vous configurez des autorisations pour différentes équipes, vous pouvez définir des autorisations par défaut pour des équipes spécifiques, puis accorder un accès privilégié à des utilisateurs spécifiques si nécessaire. L’utilisation d’Azure Kubernetes Service (AKS) avec Microsoft Entra ID vous permet de configurer Privileged Identity Management (PIM) pour les demandes juste-à-temps (JIT) pour l’accès au plan de contrôle de cluster et l’accès SSH aux nœuds.

Dans cet article, vous apprendrez comment :

  • Définissez des rôles par défaut pour des exemples de groupes pour accéder ou effectuer des opérations sur des clusters AKS et des nœuds de cluster en fonction des appartenances aux groupes Microsoft Entra.
  • Configurez des rôles de base pour accéder aux clusters AKS et à l’accès SSH aux nœuds.
  • Activation automatique des rôles pour obtenir un accès juste-à-temps aux clusters et nœuds AKS.
  • Définissez les approbateurs pour les faire approuver ou refuser les demandes d’approbation pour l’accès juste-à-temps.

Remarque

Microsoft Entra Privileged Identity Management (PIM) a des fonctionnalités Microsoft Entra ID P2 ou Gouvernance Microsoft Entra ID qui nécessitent un niveau tarifaire Premium P2. Pour plus d’informations, consultez Principes de base des licences de gouvernance des ID Microsoft Entra ainsi que le guide de tarification.

Prérequis

Cet article suppose que vous disposez d’un cluster AKS avec une intégration Microsoft Entra ID. Si vous n’en avez pas, consultez Créer un cluster AKS avec l’intégration Microsoft Entra ID.

Pour l'accès SSH aux nœuds, cet article part du principe que vous avez configuré votre cluster AKS avec SSH basé sur Entra ID. Si ce n’est pas le cas, consultez Gérer SSH pour un accès sécurisé aux nœuds Azure Kubernetes Service (AKS).

Créer des groupes de démonstration dans Microsoft Entra ID

Dans cette section, nous créons quatre groupes dans Microsoft Entra ID :

  • Par défaut : ce groupe a un accès en lecture seule (Azure Kubernetes Service RBAC Reader) aux ressources du cluster AKS.
  • Administrateur : ce groupe a un accès administrateur (Azure Kubernetes Service RBAC Admin) aux ressources du cluster AKS.
  • Accès aux nœuds : ce groupe dispose d’autorisations pour ssh dans des nœuds de cluster à l’aide de l’authentification Entra ID (Virtual Machine User Login).
  • Approbateur : ce groupe dispose des autorisations nécessaires pour approuver ou refuser les demandes d’accès juste-à-temps au cluster et aux nœuds AKS.

Vous pouvez utiliser uniquement les groupes par défaut et administrateur au lieu de créer un groupe approbateur distinct. Toutefois, si vous incluez des autorisations d’approbation au groupe administrateur, un membre qui obtient un accès juste-à-temps peut approuver ses propres demandes et les demandes d’autres utilisateurs. Nous vous déconseillons d’utiliser cette configuration dans un environnement de production, mais elle est utile à des fins de test.

Créer un groupe par défaut

  1. Commencez par obtenir l’ID de ressource de votre cluster AKS à l’aide de la commande az aks show.

    AKS_ID=$(az aks show \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query id \
    --output tsv)

  2. Commencez par obtenir l’ID de ressource de groupe de votre cluster AKS à l’aide de la commande az group show.

    RG_ID=$(az group show \
    --resource-group <resource-group-name> \
    --query id \
    --output tsv)

  3. Créez le groupe par défaut avec la commande az ad group create.

    DEFAULT_ID=$(az ad group create \
    --display-name default \
    --mail-nickname default \
    --query id \
    --output tsv)

  4. Créez une attribution de rôle Azure pour le groupe par défaut à l’aide de la commande az role assignment create.

    Il existe trois rôles que vous pouvez attribuer au groupe par défaut en fonction de vos besoins spécifiques :

    • Azure Kubernetes Service RBAC Reader : affecté à l’étendue du cluster AKS et donne un accès en lecture seule de base à la plupart des ressources du cluster.
    • Reader : affecté à l’étendue du groupe de ressources et donne un accès en lecture seule aux ressources du groupe de ressources.
    • Azure Kubernetes Service Cluster User Role : affecté à l’étendue du cluster AKS et donne accès au contexte kubeconfig pour le cluster AKS.
    # Assign the Azure Kubernetes Service RBAC Reader role to the default group
az role assignment create \
    --role "Azure Kubernetes Service RBAC Reader" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID

# Assign the Reader role to the default group
az role assignment create \
    --role "Reader" \
    --assignee $DEFAULT_ID \
    --scope $RG_ID

# Assign the Azure Kubernetes Service Cluster User Role to the default group
az role assignment create \
    --role "Azure Kubernetes Service Cluster User Role" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID

Créer un groupe administrateur

  1. Créez le groupe admin avec la commande az ad group create.

    ADMIN_ID=$(az ad group create \
    --display-name admin \
    --mail-nickname admin \
    --query id \
    --output tsv)

  2. Attribuez le rôle Azure Kubernetes Service RBAC Admin au groupe admin avec la commande az role assignment create.

    az role assignment create \
    --role "Azure Kubernetes Service RBAC Admin" \
    --assignee $ADMIN_ID \
    --scope $AKS_ID

Remarque

Si vous souhaitez permettre aux utilisateurs du groupe admin de modifier les paramètres du pool de nœuds, tels que la mise à l’échelle manuelle, vous devez créer une attribution de rôle Contributor sur le pool de nœuds de cluster à l’aide de la commande suivante :

az role assignment create \
   --role "Contributor" \
   --assignee $ADMIN_ID \
   --scope $AKS_ID/nodepools/<node-pool-name>

N’oubliez pas que cela donne uniquement l’autorisation d’effectuer une mise à l’échelle de la ressource AKS. Si vous souhaitez autoriser la mise à l’échelle à partir de la ressource Virtual Machine Scale Set, vous devez créer une affectation au niveau Virtual Machine Scale Set.

Créer un groupe approbateur

  • Créez le groupe approbateur avec la commande az ad group create.

    APPROVER_ID=$(az ad group create \
    --display-name approver \
    --mail-nickname approver \
    --query id \
    --output tsv)

Créer un groupe d’accès aux nœuds

  1. Créez le groupe d’accès aux nœuds à l’aide de la az ad group create commande.

    NODEACCESS_ID=$(az ad group create \
    --display-name node-access \
    --mail-nickname node-access \
    --query id \
    --output tsv)

  2. Obtenez l’ID de ressource du groupe de ressources de nœud (également appelé groupe de ressources d’infrastructure) à l’aide de la az aks show commande.

    NODE_RG_ID=$(az aks show \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query nodeResourceGroup \
    --output tsv)

NODE_RG_SCOPE=$(az group show \
    --name $NODE_RG_ID \
    --query id \
    --output tsv)

  3. Attribuez le Virtual Machine User Login rôle au groupe d’accès au nœud à l’aide de la commande az role assignment create.

    az role assignment create \
    --role "Virtual Machine User Login" \
    --assignee $NODEACCESS_ID \
    --scope $NODE_RG_SCOPE

    Remarque

    Si vous souhaitez accorder à l’administrateur l’accès aux nœuds à la place, utilisez le Virtual Machine Administrator Login rôle.

Créer des utilisateurs de démonstration dans Microsoft Entra ID

Dans cette section, nous créons deux utilisateurs dans Microsoft Entra ID : un utilisateur normal avec uniquement le rôle par défaut et un utilisateur privilégié qui peut approuver ou refuser des requêtes juste-à-temps provenant de l’utilisateur normal.

  1. Créez l’utilisateur normal à l’aide de la commande az ad user create. Pour les commandes de variable de mot de passe, les valeurs sont masquées afin qu’elles ne soient pas affichées sur votre console.

    DOMAIN=contoso.com
read -sp 'Enter password for NUSER_ID: ' NUSERPASSWORD
read -sp 'Enter password for PUSER_ID: ' PUSERPASSWORD

NUSER_ID=$(az ad user create \
    --display-name n01 \
    --password ${NUSERPASSWORD} \
    --user-principal-name n01@${DOMAIN} \
    --query id \
    --output tsv)

  2. Ajoutez l' utilisateur normal au groupe par défaut à l’aide de la commande az ad group member add.

    az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID

  3. Créez l’utilisateur privilégié à l’aide de la commande az ad user create.

    PUSER_ID=$(az ad user create \
    --display-name p01 \
    --password ${PUSERPASSWORD} \
    --user-principal-name p01@${DOMAIN} \
    --query id \
    --output tsv)

  4. Ajoutez l'utilisateur privilégié au groupe approbateur à l’aide de la commande az ad group member add.

    az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID

Activez Privileged Identity Management (PIM) pour le groupe administrateur

Cette section vous montre comment activer PIM pour le groupe d’administration afin de fournir un accès juste-à-temps au plan de contrôle du cluster AKS.

  1. Dans la page d’accueil du portail Azure, sélectionnez Microsoft Entra ID.
  2. Dans le menu de service, sous Gérer, sélectionnez Groupes, puis sélectionnez le groupe administrateur.
  3. Dans le menu du service, sous Activité, sélectionnez Privileged Identity Management, puis sélectionnez Activer PIM pour ce groupe.

Définir un approbateur pour le groupe d’administration

  1. Depuis la page d'accueil du portail Azure, recherchez et sélectionnez Azure AD Privileged Identity Management.

  2. Dans le menu de service, sous Gérer, sélectionnez Groupes, puis sélectionnez le groupe administrateur.

  3. Dans le menu du service, sous Gérer, sélectionnez Affectations>Ajouter des affectations.

  4. Sous l’onglet Appartenance de la page Ajouter des affectations, sélectionnez membre comme rôle et par défaut comme membre, puis sélectionnez Suivant.

  5. Sous l’onglet Paramètres, sélectionnez Éligible comme type d’affectation, puis sélectionnez Affecter.

  6. Dans le menu de service, sous Gérer, sélectionnez Paramètres>Membre>Modifier.

  7. Sur la page Modifier le paramètre de rôle - Membre, cochez la case Exiger l’approbation pour l’activation et ajoutez le groupe approbateur en tant qu’approbateur sélectionné.

    Remarque

    Si vous ne cochez pas la case Exiger l’approbation pour l’activation, les utilisateurs du groupe par défaut peuvent activer automatiquement le rôle pour obtenir un accès juste-à-temps au cluster AKS sans approbation. L’utilisateur du groupe approbateur doit être un membre de ce groupe. Même si vous définissez l’utilisateur comme propriétaire, il n’est toujours pas en mesure de passer en revue les demandes juste-à-temps, car le propriétaire du groupe a uniquement des droits d’administration pour le groupe, et non l’attribution de rôle. Vous pouvez définir l’utilisateur comme membre et propriétaire du même groupe sans conflit.

  8. Effectuez les autres changements nécessaires puis sélectionnez Mettre à jour.

Pour plus d’informations sur la configuration de PIM, consultez Configurer PIM pour les groupes.

Activer Privileged Identity Management (PIM) pour le groupe d’accès aux nœuds

Cette section vous montre comment activer PIM pour le groupe d’accès aux nœuds afin de fournir un accès SSH juste-à-temps aux nœuds de cluster.

  1. Dans la page d’accueil du portail Azure, sélectionnez Microsoft Entra ID.
  2. Dans le menu du service, sous Gérer, sélectionnez Groupes, puis sélectionnez le groupe d’accès au nœud .
  3. Dans le menu du service, sous Activité, sélectionnez Privileged Identity Management, puis sélectionnez Activer PIM pour ce groupe.

Définir un approbateur pour le groupe d’accès aux nœuds

  1. Depuis la page d'accueil du portail Azure, recherchez et sélectionnez Azure AD Privileged Identity Management.
  2. Dans le menu du service, sous Gérer, sélectionnez Groupes, puis sélectionnez le groupe d’accès au nœud .
  3. Dans le menu du service, sous Gérer, sélectionnez Affectations>Ajouter des affectations.
  4. Sous l’onglet Appartenance de la page Ajouter des affectations, sélectionnez membre comme rôle et par défaut comme membre, puis sélectionnez Suivant.
  5. Sous l’onglet Paramètres, sélectionnez Éligible comme type d’affectation, puis sélectionnez Affecter.
  6. Dans le menu de service, sous Gérer, sélectionnez Paramètres>Membre>Modifier.
  7. Sur la page Modifier le paramètre de rôle - Membre, cochez la case Exiger l’approbation pour l’activation et ajoutez le groupe approbateur en tant qu’approbateur sélectionné.
  8. Effectuez les autres changements nécessaires puis sélectionnez Mettre à jour.

Interagir avec les ressources de cluster à l’aide du rôle par défaut

À présent, nous pouvons essayer d’accéder au cluster AKS à l’aide de l’utilisateur normal, qui est membre du groupe par défaut.

  1. Connectez-vous au portail Azure en tant qu’utilisateur normal à l’aide de la commande az login.

    az login --username n01@$DOMAIN --password ${NUSERPASSWORD}

    Microsoft vous recommande d’utiliser la méthode la plus sécurisée disponible pour vous connecter à Azure. Pour plus d’informations, consultez les articles suivants :

  2. Récupérez les informations d’identification d’utilisateur pour accéder au cluster à l’aide de la commande az aks get-credentials.

    az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>

  3. Essayez d’accéder aux pods du cluster avec la commande kubectl get.

    kubectl get pods --namespace kube-system

    Vous devriez obtenir un résultat semblable à l’exemple de sortie suivant, qui affiche les pods dans l’espace de noms kube-system :

    NAME                                   READY   STATUS    RESTARTS   AGE
azure-ip-masq-agent-2rdd9              1/1     Running   0          30h
azure-policy-767c9d9d9d-886rf          1/1     Running   0          31h
cloud-node-manager-92t6h               1/1     Running   0          30h
coredns-789789675-b2dhg                1/1     Running   0          31h
coredns-autoscaler-77bbc46446-pgt92    1/1     Running   0          31h
csi-azuredisk-node-lnzrf               3/3     Running   0          30h
csi-azurefile-node-lhbxr               3/3     Running   0          31h
konnectivity-agent-7645d94b-9wqct      1/1     Running   0          30h
kube-proxy-lkx4w                       1/1     Running   0          31h
metrics-server-5955767688-lpbjb        2/2     Running   0          30h

  4. Essayez d’accéder aux secrets du cluster avec la commande kubectl get.

    kubectl get secrets --namespace kube-system

    Votre résultat devrait ressembler à l’exemple de résultat suivant, qui affiche un message d’erreur car l’utilisateur n’a pas l’autorisation d’accéder aux secrets :

    Error from server (Forbidden): secrets is forbidden: User "[email protected]" cannot list resource "secrets" in API group "" in the namespace "kube-system": User does not have access to the resource in Azure. Update role assignment to allow access.

    Le rôle Azure Kubernetes Service RBAC Reader n’a pas l’autorisation d’accéder aux secrets. Cette erreur est donc attendue.

Demander un accès juste-à-temps au cluster AKS

Cette section vous montre comment demander un accès juste-à-temps en tant qu’accès temporaire Azure Kubernetes Service RBAC Admin au plan de contrôle du cluster. Utilisez les étapes décrites dans Activer l’appartenance ou la propriété de votre groupe dans Privileged Identity Management. Pour découvrir comment approuver ou rejeter des demandes en tant qu’approbateur, consultez Approuver des demandes d’activation de membres et propriétaires de groupe.

Demander un accès SSH juste-à-temps aux nœuds de cluster

Cette section vous montre comment demander un accès SSH juste-à-temps aux nœuds de cluster en activant temporairement l’appartenance au groupe d’accès aux nœuds .

  1. Depuis la page d'accueil du portail Azure, recherchez et sélectionnez Azure AD Privileged Identity Management.
  2. Dans le menu du service, sélectionnez Mes groupes de rôles>.
  3. Recherchez le groupe d’accès aux nœuds dans la liste des affectations éligibles, puis sélectionnez Activer.
  4. Fournissez une justification pour la demande d’activation et sélectionnez Activer.
  5. Si l’approbation est requise, attendez que l’approbateur approuve votre demande. Vous recevrez une notification lorsque votre demande est approuvée.
  6. Une fois activé, vous pouvez effectuer une connexion SSH dans des nœuds de cluster à l’aide de l’authentification Entra ID.

Se connecter en SSH aux nœuds de cluster avec un accès juste-à-temps

Une fois que votre accès juste-à-temps au groupe node-access est activé, vous pouvez utiliser SSH pour vous connecter aux nœuds du cluster à l’aide de l’authentification d’Entra ID.

  1. Installez l’extension SSH pour Azure CLI :

    az extension add --name ssh

  2. Obtenez la liste des nœuds de votre cluster :

    kubectl get nodes

  3. Se connecter à un nœud à l’aide de l’authentification Entra ID :

    az ssh vm --resource-group <resource-group-name> --name <node-name>

  4. Pendant le flux d'authentification, connectez-vous avec vos informations d'identification Entra ID qui ont désormais un accès temporaire au groupe d'accès au nœud.

  5. Une fois l’authentification réussie, vous êtes connecté au nœud avec les autorisations accordées par votre attribution de rôle.

Remarque

Si vous avez configuré des stratégies d’accès conditionnel pour l’accès SSH aux nœuds, vous devez répondre à ces exigences pendant le flux d’authentification.

Interagir avec les ressources de cluster à l’aide du rôle admin

Après avoir ajouté temporairement le rôle Azure Kubernetes Service RBAC Admin, vous pouvez accéder aux ressources de cluster qui nécessitent des autorisations d’administrateur.

  1. Supprimez les jetons stockés existants à l’aide de la commande kubelogin suivante :

    kubelogin remove-tokens

    Remarque

    Si vous rencontrez une erreur en raison d’un manque d’autorisations, connectez-vous pour actualiser les autorisations à l’aide de la commande az login.

  2. Essayez d’accéder de nouveau aux secrets du cluster avec la commande kubectl get secrets.

    kubectl get secrets --namespace kube-system

    Vous devriez obtenir un résultat semblable à l’exemple de sortie suivant, qui affiche les secrets dans l’espace de noms kube-system :

    NAME                     TYPE                            DATA   AGE
bootstrap-token-sw3rck   bootstrap.kubernetes.io/token   4      35h
konnectivity-certs       Opaque                          3      35h

    L’utilisateur peut désormais accéder aux secrets, car il a le rôle Azure Kubernetes Service RBAC Admin.

Considérations relatives à la durée de vie des jetons

Selon le concept de durée de vie des jetons, si vous accordez des rôles aux utilisateurs qui utilisent des outils CLI, tels que kubectl ou kubelogin, la durée d’activation ne peut pas être inférieure à 60 minutes. Même si la durée est définie sur moins de 60 minutes, la durée effective réelle reste comprise entre 60 et 75 minutes.

Lorsque kubelogin tente d’obtenir des jetons à partir de la plateforme d’identités Microsoft, access_token et refresh_token sont retournés pour une utilisation ultérieure. Le access_token envoie des requêtes à l’API, et le refresh_token est utilisé pour obtenir un nouveau access_token lorsque celui-ci expire. Le access_token ne peut pas être révoqué une fois généré, mais le refresh_token peut être révoqué. Si le refresh_token est révoqué, l’utilisateur doit se réauthentifier pour obtenir un nouveau refresh_token. Pour révoquer manuellement le refresh_token, vous pouvez utiliser Revoke-AzureADUserAllRefreshToken.

Étapes suivantes

Pour plus d’informations, consultez les articles suivants :

  • Last updated on