Autorisierungsrollen konfigurieren

Diese Seite richtet sich an Infrastrukturbetreiber.

Auf dieser Seite werden Autorisierungsrollen, Rollenbindungen und Ressourcenzugriffsrechte für den privaten Anthos-Modus beschrieben.

Autorisierungsrollen

Der private Modus von Anthos hat vier voreingestellte Autorisierungsrollen:

Rollenname	Kubernetes ClusterRole-Name (im Administratorcluster)	Berechtigungen
Infrastrukturbetreiber	anthos-infrastructure-operator	Vollständiger Lese-/Schreibzugriff auf alle Ressourcen.
Infrastrukturbetreiber (schreibgeschützt)	anthos-infrastructure-operator-read-only	Lesezugriff auf die meisten Dinge in Anthos Management Center, ClusterRole/Role, ClusterRole/Role-Bindungen und eingeschränkten Lesezugriff auf Secrets. Nutzer haben Schreibzugriff auf Grafana, um Dashboards zu bearbeiten.
Plattformadministrator	Anthos-Plattform-Administrator	Lese-/Schreibzugriff auf Nutzercluster, Anthos-Funktionsverwaltung, Anthos Identity Service und Anthos Config Management. Lese- und Schreibzugriff auf Maschinen. Lesezugriff auf Bootstrap Service.
Plattformadministrator (schreibgeschützt)	anthos-platform-admin-read-only	Lesezugriff auf alle Elemente, die ein Plattformadministrator ansehen kann. Nutzer haben Schreibzugriff auf Grafana, um Dashboards zu bearbeiten.

Jeder Nutzer mit Zugriff auf ADMIN_KUBECONFIG wird als Mitglied in der Kubernetes-Gruppe system:master authentifiziert, was jede Aktion für den Kubernetes API-Server zulässt. Sie können beispielsweise alle Secrets auflisten, indem Sie folgenden Befehl ausführen:

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

Dabei ist ${ADMIN_KUBECONFIG} der Pfad der kubeconfig-Datei für den Administratorcluster.

Der Zugriff mit ADMIN_KUBECONFIG wird als der allgemeine Nutzername admin authentifiziert. Hierdurch wird das Erfassen der Person, die den Befehl ausführt, erschwert. Daher ist es wichtig, ADMIN_KUBECONFIG an einem sicheren Ort aufzubewahren und nur bei Bedarf zu verwenden, z. B. beim Einrichten der ersten Rollenbindungen für Plattformadministratoren oder Wiederherstellung nach OIDC-Fehlern.

Wichtig: Achten Sie darauf, dass Nutzern und Gruppen nicht das Präfix system: vorangestellt ist. Das Präfix system: ist für das Kubernetes-System reserviert.

Management Center und Messwertzugriff

Im privaten Anthos-Modus werden alle Nutzer, die an diese vier Rollen gebunden sind, automatisch in die Zulassungsliste von Management Center und der Messwerte (Grafana) synchronisiert.

Rollen mit schreibgeschützten Zugriffsrechten werden verweigert, wenn sie in Management Center eine Schreibaktion ausführen möchten.

Rollenbindungen

Beim Einrichten von OIDC in der Management Center Console können Sie einen anfänglichen Nutzer festlegen, der an die Plattformadministratorrolle gebunden ist. Bei einer angemeldeten kubeconfig für den anfänglichen Plattformadministratornutzer gibt es zwei Ansätze, um einen weiteren Nutzer an die Rolle des Plattformadministrators zu binden:

• (Empfohlen) Gruppenmitgliedschaft im OIDC-Anbieter einrichten und Rollenbindungen anhand der Gruppe erstellen
• Rollenbindungen anhand des Nutzers erstellen

(Empfohlen) Gruppenmitgliedschaft im OIDC-Anbieter einrichten und Rollenbindungen anhand der Gruppe erstellen

Bei diesem Ansatz wird eine Ihrer Gruppen an eine vordefinierte Rolle gebunden, um allen Mitgliedern der Gruppe die gleichen Zugriffsrechte wie die vordefinierte Rolle zu erteilen.

Hinweis

Prüfen Sie vor dem Start Folgendes:

• Ermitteln Sie den OIDC-Anbieter, von dem die Gruppe stammt.
• Das Feld Gruppenanforderung auf dem Tab OIDC-Profil muss mit dem Namen der Anforderung übereinstimmen, die Informationen zur Gruppenmitgliedschaft auf Ihrer OIDC-Anbieterseite enthält. Im privaten Anthos-Modus wird dieses Feld auf den Standardwert groups gesetzt. Wenn Ihr OIDC-Anbieter jedoch einen anderen Wert hat, müssen Sie diesen auf dem Tab OIDC-Profil festlegen.
• Notieren Sie sich das Gruppenpräfix auf dem Tab OIDC-Profil. Sie müssen das Gruppenpräfix vor allen Gruppennamen einfügen. Wenn Sie beispielsweise gid- als Gruppenpräfix und eine Gruppe „admin-group“ bei Ihrem OIDC-Anbieter haben, müssen Sie gid-admin-group verwenden. Beachten Sie, dass das Trennzeichen - Teil des Gruppenpräfixes ist. Das System fügt kein Trennzeichen für Sie hinzu.

Bindungen mithilfe der Management Center Console verwalten

Sie können in der Management Center Console den Tab Zugriff verwenden, um Ihre Rollenbindungen basierend auf Gruppen zu verwalten.

Sie können einer Rolle mit mehr Berechtigungen, als das aktuell angemeldete Konto hat, keine Bindung hinzufügen und dafür keine Bindung aktualisieren. Wenn Sie beispielsweise als Plattformadministrator angemeldet sind, ist es nicht möglich, eine Gruppe an eine Infrastrukturbetreiber-Rolle zu binden.

Bindungen mit kubectl verwalten

Alternativ können Sie den folgenden Befehl ausführen, um eine Rollenbindung anhand der Gruppe zu erstellen. Der an group= übergebene Wert muss mit dem Gruppennamen im OIDC-Anbieter plus dem Präfix Ihrer Gruppe übereinstimmen:

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

Jeder Nutzer, den Sie dem OIDC-Anbieter zu anthos-platform-admin-group hinzugefügt haben, hat jetzt alle Plattformadministratorberechtigungen.

Analog können Sie mit dem folgenden Befehl eine Gruppe an die Rolle „Plattformadministrator (schreibgeschützt)“ binden:

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

Um eine Rechteausweitung zu verhindern, kann ein Plattformadministrator einen Nutzer nicht an die Rolle „Infrastrukturbetreiber“ oder „Infrastrukturbetreiber (schreibgeschützt)“ binden. Zum Initialisieren der ersten Gruppe des Infrastrukturbetreibers benötigen Sie ADMIN_KUBECONFIG:

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

Danach können Sie eine KUBECONFIG mit einem angemeldeten Infrastrukturbetreiber-Konto verwenden, um andere Gruppen an beliebige Rollen zu binden:

# 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}

Rollenbindungen anhand des Nutzers erstellen

Sie können auch Rollenbindungen erstellen, die auf der Nutzerrolle basieren. Die Befehle zum Erstellen von Rollenbindungen sind mit der Verwendung einer Gruppe vergleichbar. Ersetzen Sie --group durch --user.

Sie müssen auch das Nutzerpräfix Ihres OIDC-Profils an die Nutzernamen anhängen. Wenn für Ihren OIDC-Anbieter beispielsweise das Nutzerpräfix uid- festgelegt ist und Sie [e-mail] an eine Rolle binden möchten, verwenden Sie [e-mail].

Sie können auch den Tab Zugriff in der Management Center Console verwenden, um Rollenbindungen für Nutzer zu verwalten.

Mit dem folgenden Beispielbefehl erstellen Sie eine Rollenbindung für [e-mail] und weisen ihr Plattformadministratorberechtigungen zu:

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

Wenn Sie eine Rollenbindung löschen möchten, um die Zugriffsrechte eines Nutzers zu entfernen, können Sie vorhandene Bindungen aktualisieren, anstatt sie zu löschen (z .B. Plattformadministratorrechte von [e-mail] widerrufen):

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

Sie können auch Ihren Infrastrukturbetreiber bitten, ClusterRoleBinding zu löschen.

Wichtig: Kubernetes verhindert nicht, dass ein Nutzer mit weniger Zugriffsrechten Bindungen für Nutzer mit mehr Zugriffsrechten löscht. Daher werden einem Plattformadministrator keine Löschrechte für ClusterRoleBinding gewährt. Die Verwendung von Gruppen in Ihrem OIDC-Anbieter zum Verwalten von Nutzern wird bevorzugt, da Sie stattdessen einen Nutzer aus der entsprechenden Gruppe löschen können.

Hinweise

• Weitere Informationen zur Autorisierung finden Sie unter RBAC-Autorisierung verwenden.
• In den Nutzerclustern sind keine voreingestellten Autorisierungsrollen festgelegt. Jeder API-Serverzugriff in jedem Nutzercluster ist für jeden zugänglich, der kubeconfig hat.
• Plattformadministratoren dürfen keine Rollenbindung löschen, um zu verhindern, dass Plattformadministratoren Bindungen für privilegierte Nutzer löschen. Wenn Sie den Zugriff eines Nutzers widerrufen möchten, können Sie die Rollenbindung aktualisieren, die den Nutzer an eine leere Themenliste bindet. Durch die Löschaktion auf der Seite Identität und Zugriff der Management Center Console werden auch die Rollenbindungen auf eine leere Themenliste aktualisiert, anstatt die Bindungen aus demselben Grund zu löschen.
• Der Name der Ressource ClusterRoleBinding muss eindeutig sein. Nur die neueste angewendete oder erstellte Bindung wird wirksam, wenn mehrere Clusterrollenbindungen mit demselben Namen vorhanden sind.

Kubernetes-Ressourcenzugriffsrechte für jede voreingestellte Rolle

Dieser Abschnitt enthält Details zu allen Kubernetes-Ressourcenzugriffsrechten für jede voreingestellte Rolle.

Infrastrukturbetreiber

Die Rolle des Infrastrukturbetreibers entspricht der Kubernetes-Rolle anthos-infrastructure-operator, die Verben für alle Ressourcen ausführen kann.

Infrastrukturbetreiber (schreibgeschützt)

Die Rolle „Infrastrukturbetreiber (schreibgeschützt)“ entspricht der Rolle anthos-infrastructure-operator-read-only von Kubernetes, die alle Ressourcen in den hier aufgeführten ApiGroups mit eingeschränktem Lesezugriff auf Secret lesen kann. Der Lesezugriff auf Secret ist nur auf das Zugriffstoken des Administratorclusters, die kubeconfig-Datei des Nutzerclusters und die Secrets mit dem Label logmon im kube-system für Logging und Monitoring beschränkt.

ApiGroups	Ressource	Verben
""	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
""	Dienste	get, list, watch
""	services/status	get, list, watch
""	Grafik: Bindungen	get, list, watch
""	Ereignisse	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
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

Plattformadministrator

Die Rolle des Plattformadministrators hat folgende Zugriffsrechte:

Ressource	Verben
namespaces	get, list, watch, create, update
pods	get, list, watch
services	get, list, watch
events	get, list, watch
configmaps	get, list, watch
deployments	get, list, watch
daemonsets	get, list, watch
replicasets	get, list, watch
statefulsets	get, list, watch
jobs	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

Ein Plattformadministrator hat auch Lesezugriff auf secrets, damit er eine kubeconfig-Datei abrufen kann, die bei einem Nutzercluster als cluster-admin-Rolle authentifiziert ist.

Plattformadministratoren können secrets und configmaps mit dem Label logmon im kube-system lesen und schreiben, um Logmon zu konfigurieren.

Plattformadministrator (schreibgeschützt)

Die Rolle „Plattformadministrator (schreibgeschützt)“ hat dieselben Zugriffsrechte wie „Plattformadministrator“, mit Ausnahme von:

• Alle schreibbezogenen Verben (create, update, delete) werden nicht erteilt.
• Für den Zugriff auf einen Nutzercluster kann „Plattformadministrator (schreibgeschützt)“ eine kubeconfig-Datei lesen, die als view-Rolle im Nutzercluster authentifiziert ist.