Contrôle d'accès basé sur les rôles dans les clusters Azure Operator Nexus Kubernetes

Article
10/26/2023

Cet article fournit un guide complet sur la gestion de l’accès aux clusters Nexus Kubernetes à l’aide de l’ID Microsoft Entra. Plus précisément, nous nous concentrons sur le contrôle d’accès en fonction du rôle, ce qui vous permet d’accorder des autorisations aux utilisateurs en fonction de leurs rôles ou responsabilités au sein de votre organisation.

Avant de commencer

Pour commencer, créez un groupe Microsoft Entra pour vos administrateurs de cluster et attribuez-lui des membres. Microsoft Entra ID permet d’accorder l’accès au groupe dans son ensemble, plutôt que de gérer les autorisations pour chaque utilisateur individuellement.
Utilisez l’ID de groupe que vous avez créé comme valeur pour « adminGroupObjectIds » lors de la création du cluster Kubernetes Nexus pour vous assurer que les membres du groupe obtiennent des autorisations pour gérer le cluster. Reportez-vous au guide de démarrage rapide pour obtenir des instructions sur la création et l’accès au cluster Nexus Kubernetes.

Administration istrateur d’accès au cluster

Nexus crée une liaison de rôle de cluster Kubernetes avec le rôle cluster-admin Kubernetes par défaut et les groupes Microsoft Entra que vous avez spécifiés en tant que adminGroupObjectIds. Les administrateurs de cluster ont un accès complet au cluster et peuvent effectuer toutes les opérations sur le cluster. Les administrateurs de cluster peuvent également accorder l’accès à d’autres utilisateurs en les affectant au groupe Microsoft Entra approprié.

Remarque

Lorsque vous créez un cluster Kubernetes Nexus, Nexus crée automatiquement un groupe de ressources managé dédié au stockage des ressources de cluster. Au sein de ce groupe, la ressource de cluster connectée à Arc est établie.

Pour accéder à votre cluster, vous devez configurer le paramètre kubeconfig de connexion au cluster. Après la connexion à Azure CLI avec l’entité Microsoft Entra appropriée, vous pouvez obtenir le paramètre kubeconfig nécessaire pour communiquer avec le cluster n’importe où, même en dehors du pare-feu qui l’entoure.

Définissez les variables CLUSTER_NAME, RESOURCE_GROUP et SUBSCRIPTION_ID.

CLUSTER_NAME="myNexusK8sCluster"
RESOURCE_GROUP="myResourceGroup"
SUBSCRIPTION_ID=<set the correct subscription_id>

Interroger un groupe de ressources managé avec az, puis stocker dans MANAGED_RESOURCE_GROUP

 az account set -s $SUBSCRIPTION_ID
 MANAGED_RESOURCE_GROUP=$(az networkcloud kubernetescluster show -n $CLUSTER_NAME -g $RESOURCE_GROUP --output tsv --query managedResourceGroupConfiguration.name)

La commande suivante démarre un proxy connectedk8s qui vous permet de vous connecter au serveur d’API Kubernetes du cluster Nexus Kubernetes spécifié.
```
az connectedk8s proxy -n $CLUSTER_NAME  -g $MANAGED_RESOURCE_GROUP &
```
Utilisez kubectl pour envoyer les requêtes au cluster :
```
kubectl get pods -A
```
Une réponse du cluster contenant la liste de tous les nœuds doit maintenant s’afficher.

Notes

Si le message d’erreur « Nous n’avons pas pu publier le jeton d’accès dans le proxy client. Nous n’avons pas pu nous connecter à MSI » s’affiche, vous devrez peut-être effectuer une opération az login pour vous authentifier de nouveau auprès d’Azure.

Contrôle d’accès en fonction du rôle

En tant qu’administrateur, vous pouvez fournir un contrôle d’accès en fonction du rôle au cluster en créant une liaison de rôle avec l’ID d’objet de groupe Microsoft Entra. Pour les utilisateurs qui ont uniquement besoin d’autorisations « afficher », vous pouvez accomplir la tâche en les ajoutant à un groupe Microsoft Entra lié au rôle « affichage ».

Créez un groupe Microsoft Entra pour les utilisateurs qui ont besoin d’un accès « afficher », en faisant référence au rôle Kubernetes par défaut appelé view. Ce rôle n’est qu’un exemple et, si nécessaire, vous pouvez créer des rôles personnalisés et les utiliser à la place. Pour plus d’informations sur les rôles accessibles par l’utilisateur dans Kubernetes, vous pouvez consulter la documentation officielle sur les rôles d’accès par roll-based Kubernetes.
Notez l’ID d’objet de groupe Microsoft Entra généré lors de la création.
Utilisez la commande kubectl pour créer un clusterrolebinding avec le rôle « view » et l’associer au groupe Microsoft Entra. Remplacez AZURE_AD_GROUP_OBJECT_ID par l’ID d’objet de votre groupe Microsoft Entra.
```
kubectl create clusterrolebinding nexus-read-only-users --clusterrole view --group=AZURE_AD_GROUP_OBJECT_ID
```
Cette commande crée une liaison de rôle de cluster nommée nexus-read-only-users qui attribue le view rôle aux membres du groupe Microsoft Entra spécifié.
Vérifiez que la liaison de rôle a été créée avec succès.
```
kubectl get clusterrolebinding nexus-read-only-users
```
À présent, les utilisateurs du groupe Microsoft Entra ont un accès « afficher » au cluster. Ils peuvent accéder au cluster à l’aide az connectedk8s proxy de l’affichage des ressources, mais ne peuvent apporter aucune modification

Étapes suivantes

Vous pouvez affiner davantage le contrôle d’accès en créant des rôles personnalisés avec des autorisations spécifiques. La création de ces rôles implique des ressources RoleBinding natives Kubernetes ou ClusterRoleBinding. Vous pouvez case activée la documentation Kubernetes officielle pour obtenir des conseils détaillés sur la création de rôles et de liaisons de rôles personnalisés en fonction de vos besoins.

Partager via