Configurer les rôles d'autorisation

Cette page est destinée aux opérateurs d'infrastructure.

Cette page décrit les rôles d'autorisation, les liaisons de rôles et les droits d'accès aux ressources pour le mode privé d'Anthos.

Rôles d'autorisation

Le mode privé d'Anthos possède quatre rôles d'autorisation prédéfinis :

Nom de rôle Nom ClusterRole Kubernetes (sur le cluster d'administrateur) Autorisations
Opérateur d'infrastructure anthos-infrastructure-operator Accès complet en lecture/écriture à toutes les ressources.
Opérateur d'infrastructure (lecture seule) anthos-infrastructure-operator-read-only Accès en lecture seule à la plupart des éléments du centre de gestion Anthos, aux objets ClusterRole/Role, aux ClusterRoles/Roles, aux définitions de ressources personnalisées et à un accès limité en lecture aux secrets.

Les utilisateurs disposent d'un accès en écriture à Grafana pour modifier les tableaux de bord.
Administrateur de plate-forme anthos-platform-admin
  • Accès en lecture/écriture aux clusters d'utilisateur, à 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 et aux définitions de ressources personnalisées.
Administrateur de 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 d'un accès en écriture à Grafana pour modifier les 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}

où ${ADMIN_KUBECONFIG} représente le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

L'accès à l'aide de ADMIN_KUBECONFIG est authentifié en tant que nom d'utilisateur générique admin, ce qui rend difficile 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'administrateur de plate-forme ou de la récupération en cas de défaillance OIDC).

Accéder au centre de gestion et aux métriques

Anthos en mode privé synchronise automatiquement tous les utilisateurs associés à ces quatre rôles dans la liste d'autorisation 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 du centre de gestion, vous pouvez définir une liaison initiale d'utilisateur au rôle d'administrateur de plate-forme. Avec un kubeconfig connecté pour l'administrateur de plate-forme initial, deux approches permettent de lier un autre utilisateur au rôle d'administrateur de plate-forme :

(Recommandé) 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.

Avant de commencer

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

  • Déterminez le fournisseur OIDC dont le groupe provient.
  • Le champ Groups Claim (Revendication de groupes) de l'onglet OIDC Profile (Profil OIDC) doit être identique au nom de la revendication qui contient les informations d'appartenance au groupe de votre fournisseur OIDC. Le mode privé d'Anthos attribue à ce champ une valeur par défaut de groups, mais si votre fournisseur OIDC possède une valeur différente, assurez-vous de l'avoir définie dans l'onglet OIDC Profile (Profil OIDC).
  • Notez le préfixe de groupe dans l'onglet OIDC Profile (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.

Gérer les liaisons à l'aide de la console du centre de gestion

Vous pouvez gérer les liaisons de rôles basées sur les groupes à l'aide de l'onglet Accès de la console du centre de gestion.Appliquer le profil d'identité lors de la création du cluster

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.

Gérer les liaisons à l'aide de kubectl

Vous pouvez exécuter la commande suivante pour créer une liaison de rôle basée sur un groupe. 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

Tous les utilisateurs ajoutés à anthos-platform-admin-group dans le fournisseur OIDC disposent désormais de toutes les autorisations d'administrateur de plate-forme.

De même, vous pouvez exécuter 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 l'élévation des 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=anthos-infrastructure-operator --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=anthos-infrastructure-operator-read-only --group=gid-anthos-platform-operator-read-only-group --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Créer des liaisons de rôles basées sur 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. Remplacez --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 joedoe@example.com à un rôle, utilisez uid-joedoe@example.com.

Vous pouvez également gérer les liaisons de rôles des utilisateurs dans l'onglet Accès de la console du centre de gestion.

Voici un exemple de commande permettant de créer une liaison de rôle pour charlie@example.com et de lui accorder des autorisations d'administrateur de plate-forme :

kubectl create clusterrolebinding charlie-platform-admin-binding \
  --clusterrole=anthos-platform-admin --user=uid-charlie@example.com --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 charlie@example.com 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.

Remarques

  • Pour en savoir plus sur les autorisations, consultez la page Utiliser l'autorisation RBAC.
  • Aucun rôle d'autorisation prédéfini n'est configuré dans les clusters d'utilisateur. 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 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 droits 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 sur la page Identité et accès de la console du centre de gestion 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 la ressource ClusterRoleBinding doit être unique. Seule la dernière liaison appliquée ou créée prend effet lorsqu'il existe plusieurs liaisons de rôles 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

Le rôle d'opérateur d'infrastructure correspond au rôle anthos-infrastructure-operator Kubernetes, qui peut exécuter n'importe quel verbe sur n'importe quelle ressource.

Opérateur d'infrastructure (lecture seule)

Le rôle d'opérateur d'infrastructure (lecture seule) correspond au rôle anthos-infrastructure-operator-read-only Kubernetes, qui peut lire toutes les ressources des groupes d'API répertoriés ici avec un accès en lecture limité à Secret. L'accès en lecture à Secret est limité aux jetons d'accès du cluster d'administrateur, au fichier kubeconfig du cluster d'utilisateur, et aux secrets disposant du libellé logmon dans kube-system pour la journalisation et la surveillance.

ApiGroups Ressource Verbes
"" ConfigMaps get, list, watch
"" endpoints get, list, watch
"" persistentvolumeclaims get, list, watch
"" persistentvolumeclaims/status get, list, watch
"" pods get, list, watch
"" replicationcontrollers get, list, watch
"" replicationcontrollers/scale get, list, watch
"" serviceaccounts get, list, watch
"" services get, list, watch
"" services/status get, list, watch
"" bindings get, list, watch
"" événement get, list, watch
"" limitranges get, list, watch
"" namespaces/status get, list, watch
"" pods/log get, list, watch
"" pods/status get, list, watch
"" replicationcontrollers/status get, list, watch
"" resourcequotas get, list, watch
"" resourcequotas/status get, list, watch
"" namespaces get, list, watch
apiextensions.k8s.io customresourcedefinitions get, list, watch
apps * get, list, watch
autoscaling * get, list, watch
batch * get, list, watch
cert-manager.io * get, list, watch
extensions * get, list, watch
metrics.k8s.io * get, list, watch
networking.k8s.io * get, list, watch
policy * get, list, watch
rbac.authorization.k8s.io * get, list, watch
addons.gke.io * get, list, watch
authentication.gke.io * get, list, watch
baremetal.cluster.gke.io * get, list, watch
cluster.x-k8s.io * get, list, watch
managementcenter.anthos.cloud.google.com * get, list, watch

Administrateur de plate-forme

Le rôle d'administrateur de plate-forme dispose 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
domainconfigs.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
customresourcedefinitions.apiextensions.k8s.io get, list, watch

Les administrateurs de plate-forme disposent d'un accès en lecture à secrets pour leur permettre d'obtenir un fichier kubeconfig authentifié en tant que rôle cluster-admin pour un cluster d'utilisateur.

Les administrateurs de plate-forme peuvent lire et écrire des secrets et configmaps avec un libellé logmon dans kube-system afin de configurer Logmon.

Administrateur de plate-forme (lecture seule)

L'administrateur de plate-forme (en lecture seule) dispose des mêmes droits d'accès que l'administrateur de 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.

Étapes suivantes