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

Article
10/15/2024

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 requêtes juste-à-temps (JIT).

Dans cet article, vous apprendrez comment :

Définissez des rôles par défaut à des exemples de groupes pour leur permettre d’accéder ou d’effectuer des opérations sur des clusters AKS en fonction de leur appartenance aux groupes Microsoft Entra.
Configurez des rôles de base pour accéder aux clusters AKS.
Activation automatique des rôles pour obtenir un accès juste-à-temps aux clusters 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 fondamentaux 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.

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

Dans cette section, nous créons trois 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.
Approbateur: ce groupe dispose des autorisations nécessaires pour approuver ou refuser des demandes pour l’accès juste-à-temps au cluster 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 il est utile à des fins de test.

Créer un groupe par défaut

Obtenez l’ID de ressource du cluster AKS avec la commande az aks show.

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

Obtenez l’ID de groupe de ressource du cluster AKS avec la commande az group show.

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

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)

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

Créez le groupe administrateur à l’aide de la commande az ad group create.

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

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 administrateur 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 de groupe de machines virtuelles identiques, vous devez créer une affectation au niveau du groupe de machines virtuelles identiques.

Créer un groupe approbateur

Créez le groupe approbateur à l’aide de la commande az ad group create.

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

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 à partir de l’utilisateur normal.

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

DOMAIN=contoso.com
PASSWORD=Password1

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

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

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 ${PASSWORD} \
    --user-principal-name p01@${DOMAIN} \
    --query id \
    --output tsv)

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

Dans la page d’accueil du Portail Azure, sélectionnez Microsoft Entra ID.
Dans le menu de service, sous Gérer, sélectionnez Groupes, puis sélectionnez le groupe administrateur.
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

Dans la page d’accueil du portail Azure, recherchez et sélectionnez Privileged Identity Management.
Dans le menu de service, sous Gérer, sélectionnez Groupes, puis sélectionnez le groupe administrateur.
Dans le menu du service, sous Gérer, sélectionnez Affectations>Ajouter des affectations.
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.
Sous l’onglet Paramètres, sélectionnez éligible comme type d’affectation, puis sélectionnez Affecter.
Dans le menu de service, sous Gérer, sélectionnez Paramètres>Membre>Modifier.
Dans 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.
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.

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.

Connectez-vous au portail Azure en tant qu’utilisateur normal à l’aide de la commande az login.
```
az login --username n01@$DOMAIN --password ${PASSWORD}
```
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>
```

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

Essayez d’accéder aux secrets du cluster à l’aide de 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 fois, nous pouvons demander un accès juste-à-temps en tant que Azure Kubernetes Service RBAC Admin temporaire à l’aide des é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.

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.

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.
Essayez d’accéder aux secrets du cluster de nouveau à l’aide de 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 :

Partager via