Configurer les rôles d'autorisation

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Rôles d'autorisation

Le mode privé d'Anthos est fourni avec quatre rôles d'autorisation prédéfinis :

Nom du rôle	Nom ClusterRole Kubernetes (sur le cluster d'administrateur)	Autorisations
Opérateur d'infrastructure	cluster-admin	Accès complet en lecture/écriture à toutes les ressources.
Opérateur d'infrastructure (lecture seule)	vue	Accès en lecture seule à la plupart des éléments du centre de gestion, à l'exception des rôles, des liaisons de rôles et des secrets. Les utilisateurs disposent actuellement d'un accès en écriture à Grafana pour modifier des tableaux de bord.
Administrateur de la plate-forme	anthos-platform-admin	Accès en lecture/écriture aux clusters d'utilisateurs, à la gestion des fonctionnalités Anthos, à Anthos Identity Service et à Anthos Config Management. Accès en lecture/suppression aux machines. Accès en lecture seule au service d'amorçage.
Administrateur de la plate-forme (Lecture seule)	anthos-platform-admin-read-only	Accès en lecture seule à tout ce qu'un administrateur de plate-forme peut afficher. Les utilisateurs disposent actuellement d'un accès en écriture à Grafana pour modifier des tableaux de bord.

Toute personne ayant accès à ADMIN_KUBECONFIG est authentifiée en tant que membre du groupe Kubernetes system:master, ce qui permet d'effectuer toute action sur le serveur d'API Kubernetes. Par exemple, ils peuvent répertorier tous les secrets en exécutant la commande suivante:

kubectl get secrets --all-namespaces --kubeconfig=${ADMIN_KUBECONFIG}

L'accès à l'aide de ADMIN_KUBECONFIG est authentifié en tant que nom d'utilisateur générique admin, ce qui complique le suivi de la personne qui exécute la commande. Par conséquent, il est important de conserver ADMIN_KUBECONFIG en lieu sûr et de l'utiliser uniquement lorsque cela est nécessaire (par exemple, lors de la configuration des liaisons initiales du rôle d'opérateur de plate-forme ou de la récupération en cas de défaillance OIDC).

IMPORTANT: Assurez-vous que les utilisateurs et les groupes ne portent pas le préfixe system:. Le préfixe system: est réservé au système Kubernetes.

Console Web et accès aux métriques

Anthos en mode privé synchronise automatiquement tous les utilisateurs associés à ces quatre rôles dans la liste autorisée du centre de gestion et de l'accès aux métriques (Grafana).

Les rôles disposant de droits d'accès en lecture seule sont refusés s'ils tentent d'effectuer une action d'écriture dans le centre de gestion.

Liaisons de rôles

Lors de la configuration d'OIDC dans la console Web, vous pouvez définir un utilisateur initial lié au rôle d'administrateur de plate-forme. Avec un kubeconfig connecté pour l'utilisateur administrateur de la plate-forme initial, deux approches permettent de lier un autre utilisateur au rôle d'administrateur de plate-forme:

Méthode I: (recommandée) configurer l'appartenance à un groupe dans le fournisseur OIDC et créer des liaisons de rôles basées sur un groupe

Cette approche associe un de vos groupes à un rôle prédéfini afin d'accorder à tous les membres du groupe les mêmes droits d'accès que le rôle prédéfini.

Vérifiez les éléments suivants avant de commencer:

• Déterminez le fournisseur OIDC dont le groupe provient.
• Le champ "Revendications de groupe" de l'onglet "Profil OIDC" doit être identique au nom de la revendication contenant les informations d'appartenance à un groupe côté fournisseur OIDC. Anthos en mode privé lui attribue une valeur par défaut: groups. Toutefois, si votre fournisseur OIDC en a un autre, assurez-vous de l'avoir défini dans votre onglet "Profil OIDC".
• Notez le "Préfixe de groupe" dans l'onglet "Profil OIDC". Vous devez inclure le préfixe de groupe avant tous les noms de groupe. Par exemple, si vous avez gid- comme préfixe de groupe et un groupe "admin-group" dans votre fournisseur OIDC, vous devez utiliser gid-admin-group. Notez que le séparateur - correspond à la partie du préfixe de groupe et que le système n'ajoute aucun séparateur pour vous.

Vous pouvez gérer les liaisons de rôles en fonction de groupes à l'aide de l'onglet de gestion des accès de l'interface utilisateur du centre de gestion.

Vous ne pouvez pas ajouter ni mettre à jour une liaison à un rôle disposant de plus de privilèges que votre compte actuel. Par exemple, si vous êtes connecté en tant qu'administrateur de plate-forme, vous ne pouvez pas lier un groupe à un rôle d'opérateur d'infrastructure.

Vous pouvez par contre exécuter la commande suivante pour créer une liaison de rôle basée sur Group. La valeur transmise à group= doit être identique au nom de votre groupe dans le fournisseur OIDC avec le préfixe de votre groupe:

kubectl create clusterrolebinding anthos-platform-admin-group-binding \
--kubeconfig=${ADMIN_OIDC_KUBECONFIG} --clusterrole=anthos-platform-admin \
--group=gid-anthos-platform-admin-group

Les utilisateurs ajoutés à anthos-platform-admin-group dans le fournisseur OIDC disposent désormais de toutes les autorisations en tant qu'administrateurs de la plate-forme.

De même, vous pouvez utiliser la commande suivante pour lier un groupe au rôle Administrateur de plate-forme (lecture seule) :

kubectl create clusterrolebinding anthos-platform-admin-read-only-group-binding \
  --kubeconfig=${ADMIN_OIDC_KUBECONFIG} --clusterrole=anthos-platform-admin-read-only \
  --group=gid-anthos-platform-admin-read-only-group

Pour éviter la transmission de privilèges, un administrateur de plate-forme ne peut pas lier un groupe à un opérateur d'infrastructure ou à un rôle d'opérateur d'infrastructure (en lecture seule). Pour initialiser le premier groupe d'opérateurs d'infrastructure, vous avez besoin de ADMIN-KUBECONFIG:

kubectl create clusterrolebinding anthos-platform-operator-group-binding \
  --kubeconfig=${ADMIN_KUBECONFIG} --clusterrole=cluster-admin --group=gid-anthos-platform-operator-group

Vous pouvez ensuite utiliser un KUBECONFIG avec un compte d'opérateur d'infrastructure connecté pour lier d'autres groupes à des rôles:

# Bind a group to Infrastructure Operator (Read Only):
kubectl create clusterrolebinding anthos-platform-operator-read-only-binding \
  --clusterrole=view --group=gid-anthos-platform-operator-read-only-group --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Méthode II: créer des liaisons de rôles en fonction de l'utilisateur

Vous pouvez également créer des liaisons de rôle basées sur le rôle utilisateur. Les commandes permettant de créer des liaisons de rôles sont semblables à l'utilisation de groupe. Vous devez remplacer --group par --user.

Vous devez également ajouter le préfixe d'utilisateur de votre profil OIDC à chaque nom d'utilisateur. Par exemple, si votre fournisseur OIDC est configuré pour avoir un préfixe utilisateur uid- et que vous souhaitez lier [e-mail] à un rôle, utilisez [e-mail].

Vous pouvez également utiliser l'onglet de gestion des accès pour gérer les liaisons de rôles pour les utilisateurs.

Vous trouverez ci-dessous un exemple de commande permettant de créer une liaison de rôle pour [e-mail] et de lui attribuer les autorisations d'administrateur de plate-forme:

kubectl create clusterrolebinding charlie-platform-admin-binding \
  --clusterrole=anthos-platform-admin --user=[e-mail] --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Pour supprimer une liaison de rôle afin de révoquer les droits d'accès d'un utilisateur, mettez à jour les liaisons existantes au lieu de les supprimer (par exemple, révoquer le droit d'administrateur de [e-mail] de la plate-forme) :

kubectl patch clusterrolebinding charlie-platform-admin-binding \
  -p '{"subjects":[]}' --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Vous pouvez également demander à votre opérateur d'infrastructure de supprimer ClusterRoleBinding.

BONNES PRATIQUES : Kubernetes n'empêche pas un utilisateur disposant de droits d'accès inférieurs de supprimer les liaisons des utilisateurs disposant de droits d'accès plus élevés. Par conséquent, l'administrateur de la plate-forme n'est pas autorisé à supprimer ClusterRoleBinding. Pour gérer les utilisateurs, il est préférable d'utiliser les groupes de votre fournisseur OIDC, car vous pouvez supprimer un utilisateur du groupe correspondant.

Remarques

• Pour plus d'informations, consultez le contrôle des accès basé sur les rôles (RBAC, Role-Based Access Control) dans la documentation officielle.
• Aucun rôle d'autorisation prédéfini n'a été défini dans les clusters d'utilisateurs. L'accès au serveur d'API Kubernetes dans chaque accès au cluster d'utilisateur est ouvert à toute personne disposant du fichier kubeconfig.
• Les administrateurs de la plate-forme ne sont pas autorisés à supprimer une liaison de rôle pour empêcher les administrateurs de plate-forme de supprimer des liaisons pour les utilisateurs disposant de privilèges plus élevés. Pour révoquer l'accès d'un utilisateur, vous pouvez mettre à jour la liaison de rôle qui l'associe à une liste d'objet vide. L'action de suppression dans l'interface utilisateur de gestion des accès met également à jour les liaisons de rôles vers une liste d'objet vide au lieu de supprimer les liaisons pour la même raison.
• Le nom de ClusterRoleBinding doit être unique. Seule la dernière liaison appliquée/créée prendra effet lorsqu'il existe plusieurs liaisons de rôle de cluster portant le même nom.

Droits d'accès aux ressources Kubernetes pour chaque rôle prédéfini

Cette section fournit des détails sur tous les droits d'accès aux ressources Kubernetes pour chaque rôle prédéfini.

Opérateur d'infrastructure

Opérateur d'infrastructure correspond au rôle Kubernetes intégré cluster-admin, qui peut exécuter n'importe quel verbe sur n'importe quelle ressource.

Opérateur d'infrastructure (lecture seule)

Opérateur d'infrastructure (lecture seule) correspond au rôle k8s intégréview qui peut lire toutes les ressources, saufRole, ClusterRole, RoleBinding, ClusterRoleBinding etSecret.

Étant donné que de nombreuses informations utiles telles que le fichier kubeconfig du cluster d'utilisateur sont stockées en tant que Secrets, l'opérateur d'infrastructure (lecture seule) n'est pas totalement fonctionnel.

Administrateur de la plate-forme

L'administrateur de plate-forme peut disposer des droits d'accès suivants:

Ressource	Verbes
namespaces	get, list, watch, create, update
pods	get, list, watch
services	get, list, watch
événement	get, list, watch
ConfigMaps	get, list, watch
deployments	get, list, watch
daemonsets	get, list, watch
replicasets	get, list, watch
statefulsets	get, list, watch
tâches	get, list, watch
cronjobs	get, list, watch
memberships.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
onpremuserclusters.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
clusters.baremetal.cluster.gke.io	get, list, watch, create
nodepools.baremetal.cluster.gke.io	get, list, watch, create
clusters.cluster.x-k8s.io	get, list, watch
machines.baremetal.cluster.gke.io	get, list, watch
inventorymachines.baremetal.cluster.gke.io	get, list, watch
addresspools.managementcenter.anthos.cloud.google.com	get, list, watch
bootstrapservicebindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
bootstrapservices.managementcenter.anthos.cloud.google.com	get, list, watch
bootstrapservicebindingitems.managementcenter.anthos.cloud.google.com	get, list, watch
adminoperators.managementcenter.anthos.cloud.google.com	get, list, watch
clientconfigs.authentication.gke.io	get, list, watch, create, update, delete
configmanagementbindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
configmanagementfeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
configmanagementbindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshbindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshfeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshbindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicebindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicefeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicebindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
updatablecomponents.managementcenter.anthos.cloud.google.com	get, list, watch
domainidpmappings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
domainidpmappings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
logmons.addons.gke.io	get, list, watch, create, update, delete
clusterrolebindings.rbac.authorization.k8s.io	get, list, watch, create, update

L'administrateur de plate-forme dispose également d'un accès en lecture à secrets pour lui permettre d'obtenir un fichier kubeconfig authentifié en tant que rôle cluster-admin pour un cluster d'utilisateur.

L'administrateur de plate-forme peut également lire et écrire secrets et configmaps avec un libellé logmon dans kube-system afin de configurer Logmon.

Administrateur de la plate-forme (lecture seule)

L'administrateur de la plate-forme (lecture seule) dispose des mêmes droits d'accès que l'administrateur de la plate-forme, à quelques exceptions près:

• Tous les verbes liés à l'écriture (créer, mettre à jour et supprimer) ne sont pas autorisés.
• Pour un accès à un cluster d'utilisateur, l'administrateur de plate-forme (lecture seule) ne peut lire qu'un fichier kubeconfig authentifié en tant que rôle view dans le cluster d'utilisateur.