Contrôle d'accès basé sur les rôles dans les clusters Azure Operator Nexus Kubernetes
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
etSUBSCRIPTION_ID
.CLUSTER_NAME="myNexusK8sCluster" RESOURCE_GROUP="myResourceGroup" SUBSCRIPTION_ID=<set the correct subscription_id>
Interroger un groupe de ressources managé avec
az
, puis stocker dansMANAGED_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 leview
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.