Aktionen in Clustern mit rollenbasierter Zugriffssteuerung autorisieren

Autopilot Standard

---

Auf dieser Seite wird beschrieben, wie Sie Aktionen für Ressourcen in Ihren Google Kubernetes Engine-Clustern (GKE) mithilfe des integrierten Mechanismus für rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Kubernetes autorisieren.

RBAC ist ein zentrales Sicherheitsfeature in Kubernetes, mit dem Sie detaillierte Berechtigungen erstellen können, um zu verwalten, welche Aktionen Nutzer und Arbeitslasten für Ressourcen in Ihren Clustern ausführen können. Als Plattformadministrator erstellen Sie RBAC-Rollen und binden diese Rollen an Subjekte, die authentifizierte Nutzer wie Dienstkonten oder Gruppen sind. Kubernetes RBAC ist standardmäßig aktiviert.

Vorbereitung

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

• Lesen Sie die Best Practices für RBAC für GKE. Dort erfahren Sie, wie Sie das Design Ihrer RBAC-Richtlinien verbessern können.

Interaktion mit der Identitäts- und Zugriffsverwaltung

Sie können sowohl Identity and Access Management (IAM) als auch Kubernetes RBAC verwenden, um den Zugriff auf den GKE-Cluster zu steuern:

• IAM ist kein spezifisches Kubernetes-Produkt. Es bietet eine Identitätsverwaltung für mehrere Google Cloud-Produkte und wird hauptsächlich auf Ebene des Google Cloud-Projekts verwendet.

• Kubernetes RBAC ist eine Kernkomponente von Kubernetes und ermöglicht Ihnen, Rollen (Sätze von Berechtigungen) für jedes Objekt oder jeden Objekttyp im Cluster zu erstellen und zu gewähren.

• Zum Autorisieren einer Aktion prüft GKE zuerst nach einer RBAC-Richtlinie. Wenn keine RBAC-Richtlinie vorhanden ist, prüft GKE die IAM-Berechtigungen.

IAM und Kubernetes RBAC sind in GKE eingebunden, Nutzer zum Ausführen von Aktionen zu autorisieren, sofern sie laut einem der beiden Tools ausreichende Berechtigungen haben. Dies ist ein wichtiger Teil beim Bootstrapping eines GKE-Clusters, da Google Cloud-Nutzer standardmäßig keine Kubernetes-RBAC-Rollenbindungen (RoleBinding-Objekte) haben.

Zum Autorisieren von Nutzern mithilfe von Google Cloud-Konten muss der Client korrekt konfiguriert sein und diese Konten zuerst authentifizieren. Wenn Sie beispielsweise kubectl verwenden, müssen Sie den kubectl-Befehl für die Authentifizierung bei Google Cloud konfigurieren, bevor Befehle ausgeführt werden, die eine Autorisierung erfordern.

Hinweis: Viele Fehler, die anscheinend auf die Autorisierung zurückzuführen sind, werden tatsächlich vom Cluster verursacht, weil dieser den Client nicht authentifizieren kann. Beispielsweise gibt es spezielle Anforderungen für die Authentifizierung von Compute Engine-Instanzen, die unter Clusterzugriff für kubectl beschrieben werden.

In fast allen Fällen kann Kubernetes RBAC anstelle von IAM verwendet werden. GKE-Nutzer benötigen in dem Projekt, das den Cluster enthält, mindestens die IAM-Berechtigung container.clusters.get. Diese Berechtigung ist in der Rolle container.clusterViewer und in anderen Rollen mit höheren Berechtigungen enthalten. Die Berechtigung container.clusters.get ist erforderlich, damit Nutzer sich bei den Clustern im Projekt authentifizieren können. Sie sind jedoch nicht autorisiert, Aktionen innerhalb dieser Cluster auszuführen. Die Autorisierung kann dann entweder von IAM oder Kubernetes RBAC bereitgestellt werden.

Berechtigungen definieren und zuweisen

Sie können RBAC-Regeln in ClusterRole- und Role-Objekten definieren und diese Regeln dann so mit ClusterRoleBinding- und RoleBinding-Objekten zuweisen:

• ClusterRole: Eine Gruppierung von Ressourcen und zulässigen Vorgängen auf Clusterebene, die Sie einem Nutzer oder einer Gruppe über RoleBinding oder ClusterRoleBinding zuweisen können.
• Role: Eine Namespace-Gruppierung von Ressourcen und zulässigen Vorgängen, die Sie einem Nutzer oder einer Gruppe von Nutzern mit einem RoleBinding zuweisen können.
• ClusterRoleBinding: Weisen Sie einem Nutzer oder einer Gruppe für alle Namespaces im Cluster eine ClusterRole zu.
• RoleBinding: Weisen Sie einem Nutzer oder einer Gruppe in einem bestimmten Namespace einen Role oder einen ClusterRole zu.

Wenn Sie RoleBinding verwenden, um einem Nutzer oder einer Gruppe eine ClusterRole zuzuweisen, können diese Nutzer und Gruppen nur auf Ressourcen in dem Namespace zugreifen, den Sie in RoleBinding angegeben haben. Wenn Sie möchten, dass die Nutzer oder Gruppen in allen Namespaces auf Ressourcen zugreifen, verwenden Sie stattdessen ein ClusterRoleBinding.

Hinweis: RBAC-Rollen sind additiv. Es sind keine deny-Regeln vorhanden. Stellen Sie sich beim Strukturieren Ihrer RBAC-Rollen jede Rolle als Zugriff auf Ressourcen vor.

Berechtigungen mithilfe von Roles- oder ClusterRoles-Objekten definieren

Sie definieren Berechtigungen in einem Role- oder ClusterRole-Objekt. Ein Role-Objekt definiert den Zugriff auf Ressourcen in genau einem Namespace, während ein ClusterRole-Objekt den Zugriff auf Ressourcen im gesamten Cluster festlegt.

Role- und ClusterRole-Objekte haben dieselbe Syntax. Jedes Objekt enthält den Abschnitt rules, in dem Sie die Ressourcen definieren, für die die Regel gelten soll, und die zulässigen Vorgänge für die Rolle. Das folgende Role-Objekt gewährt beispielsweise Lesezugriff (get, watch und list) für alle Pods im Namespace accounting:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: accounting
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Eine vollständige Liste der zulässigen Felder finden Sie in der API-Dokumentation zu Role und ClusterRole.

Hinweis: Damit Sie ein Role-Objekt zum Definieren von Berechtigungen erstellen können, müssen Sie die im Role-Objekt definierten Berechtigungen bereits haben. Wenn Ihnen die IAM-Rolle cluster-admin zugewiesen wurde, reicht das aus.

Role im Vergleich zu ClusterRole

Da die von einem ClusterRole-Objekt gewährten Berechtigungen im gesamten Cluster gelten, können Sie mit ClusterRole-Objekten den Zugriff auf andere Arten von Ressourcen steuern, als dies mit Role-Objekten möglich ist. Dazu gehören:

• Clusterressourcen wie Knoten
• REST-Endpunkte wie /healthz, die keine Ressourcen sind
• Namespace-Ressourcen in allen Namespaces (z. B. alle Pods im gesamten Cluster, unabhängig vom jeweiligen Namespace)

Rollen mithilfe von RoleBinding- oder ClusterRoleBinding-Objekten zuweisen

Nachdem Sie ein Role- oder ClusterRole-Objekt erstellt haben, weisen Sie es einem Nutzer oder einer Gruppe von Nutzern zu. Dazu erstellen Sie ein RoleBinding- oder ClusterRoleBinding-Objekt. Nutzer und Gruppen heißen subjects und können Folgendes sein:

Subject-Typ	Wert für kind	Wert für name
Google Cloud-Nutzerkonto	User	Bei Google Cloud registrierte E-Mail-Adresse
Kubernetes-Dienstkonto	ServiceAccount	Name eines Kubernetes-ServiceAccount-Objekts im Cluster
IAM-Dienstkonto	User	Automatisch generierte E-Mail-Adresse des IAM-Dienstkontos
Google-Gruppe-Adresse in einer bestätigten Domain	Group	E-Mail-Adresse einer Google Workspace-Gruppe, die Mitglied der Gruppe gke-security-groups ist. Eine Anleitung zum Einrichten von Google Groups for RBAC finden Sie unter Google Groups for RBAC konfigurieren.

Mit dem folgenden RoleBinding-Objekt wird einem Nutzer, einem Kubernetes-Dienstkonto, einem IAM-Dienstkonto und einer Google-Gruppe die Rolle pod-reader gewährt:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: accounting
subjects:
# Google Cloud user account
- kind: User
  name: [e-mail]
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: [e-mail]
# Google Group
- kind: Group
  name: [e-mail]
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

API-Zugriff mit kubectl prüfen

kubectl stellt den Unterbefehl auth can-i zum schnellen Abfragen der API-Autorisierungsebene bereit. Als Plattformadministrator müssen Sie möglicherweise die Identität von Nutzern übernehmen, um zu bestimmen, welche Aktionen sie ausführen können. Sie können auth can-i verwenden und ein zusätzliches --as-Flag übergeben.

Wenn Sie den Befehl kubectl auth can-i ohne das Flag --as ausführen, führt die Identitäts- und Zugriffsverwaltung (IAM) die Autorisierung durch. Wenn Sie dagegen das Flag --as anhängen, führt Kubernetes RBAC die Autorisierung aus. Daher müssen Sie die erforderlichen Role- und RoleBinding-Objekte für RBAC erstellen.

Weitere Informationen finden Sie unter API-Zugriff überprüfen.

API-Nutzung und Beispiele

Ausführliche Informationen zur Verwendung der Kubernetes API zum Erstellen der erforderlichen Role-, ClusterRole-, RoleBinding- und ClusterRoleBinding-Objekte für RBAC finden Sie in der Kubernetes-Dokumentation unter Using RBAC Authorization.

Fehlerbehebung

Zum Beheben von Problemen mit RBAC verwenden Sie das Audit-Log für Administratoraktivitäten, das standardmäßig für alle Cluster aktiviert ist. Wenn der Zugriff auf eine Ressource oder einen Vorgang aufgrund fehlender Berechtigungen verweigert wird, protokolliert der API-Server den Fehler RBAC DENY sowie zusätzliche Informationen wie die implizite und explizite Gruppenmitgliedschaft des Nutzers. Wenn Sie Google Groups for RBAC verwenden, wird google groups in der Lognachricht angezeigt.

Beschränkungen

In den folgenden Abschnitten werden Interaktionen beschrieben, die bei der Arbeit mit Kubernetes RBAC und IAM möglicherweise nicht offensichtlich sind.

Standardrollen für die Erkennung

Cluster werden mit einem Satz von ClusterRole- und ClusterRoleBinding-Standardobjekten erstellt. Anfragen mit gültigen Anmeldedaten werden in der Gruppe system:authenticated abgelegt, während alle anderen Anfragen in die Gruppe system:unauthenticated fallen.

Mit dem ClusterRole-Objekt system:basic-user können Nutzer SelfSubjectAccessReviews ausführen, um die eigenen Berechtigungen im Cluster zu testen. Die Rolle system:discovery ermöglicht Nutzern, Discovery APIs zu lesen. Diese können Informationen über CustomResourceDefinitions enthalten, die dem Cluster hinzugefügt wurden.

Anonyme Nutzer (system:unauthenticated) erhalten stattdessen die ClusterRole system:public-info-viewer, die Lesezugriff auf die APIs /healthz und /version gewährt.

Führen Sie den folgenden Befehl aus, um die vom ClusterRole-Objekt system:discovery zugelassenen API-Endpunkte aufzurufen:

kubectl get clusterroles system:discovery -o yaml

Forbidden-Fehler für Dienstkonten auf Google Cloud-VM-Instanzen

Der folgende Fehler kann auftreten, wenn die VM-Instanz nicht den Bereich userinfo-email hat:

Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...

Angenommen, die VM hat den Bereich cloud-platform, aber nicht den Bereich userinfo-email. Wenn die VM ein Zugriffstoken erhält, verknüpft Google Cloud dieses Token mit dem Bereich cloud-platform. Wenn der Kubernetes API-Server dann die mit dem Zugriffstoken verknüpfte Identität bei Google Cloud anfordert, erhält er die eindeutige ID des Dienstkontos, nicht die E-Mail-Adresse des Dienstkontos.

Für eine erfolgreiche Authentifizierung erstellen Sie entweder eine neue VM mit dem Bereich userinfo-email oder eine neue Rollenbindung, die die eindeutige ID verwendet.

Führen Sie den folgenden Befehl aus, um eine neue VM-Instanz mit dem Bereich userinfo-email zu erstellen:

gcloud compute instances create INSTANCE_NAME \
    --service-account SERVICE_ACCOUNT_EMAIL \
    --scopes userinfo-email

Führen Sie die folgenden Schritte aus, um eine neue Rollenbindung zu erstellen, die die eindeutige ID des Dienstkontos für eine vorhandene VM verwendet:

1. Ermitteln Sie die eindeutige ID des Dienstkontos:

   gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL
   

   In der folgenden Ausgabe wird beispielsweise uniqueId für das Dienstkonto [e-mail] angezeigt:

   displayName: Some Domain IAM service account
   email: [e-mail]
   etag: BwWWja0YfJA
   name: projects/project-name/serviceAccounts/[e-mail]
   oauth2ClientId: '123456789012345678901'
   projectId: project-name
   uniqueId: '123456789012345678901'
   

2. Erstellen Sie eine Rollenbindung mit der uniqueId des Dienstkontos:

   kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \
       --clusterrole cluster-admin \
       --user UNIQUE_ID
   

Berechtigung zum Erstellen oder Aktualisieren von Rollen und Rollenbindungen

In Kubernetes können Sie eine Rolle oder Rollenbindung mit bestimmten Berechtigungen nur erstellen oder aktualisieren, wenn Sie die folgenden Bedingungen erfüllen:

• Rolle erstellen oder aktualisieren: Sie müssen bereits dieselben Berechtigungen haben, die Sie der Rolle zuweisen möchten. Alternativ müssen Sie berechtigt sein, das Verb escalate für die Rolle auszuführen.
• Erstellen oder aktualisieren Sie eine Rollenbindung: Sie müssen bereits dieselben Berechtigungen haben, die in der gebundenen Rolle gewährt werden, und zwar mit demselben Bereich wie die Rollenbindung. Alternativ müssen Sie berechtigt sein, das Verb bind für die referenzierte Rolle auszuführen.

Wenn Ihnen die Berechtigungen, die Sie in der Rolle gewähren, ursprünglich mit einer IAM-Zulassungsrichtlinie anstelle von RBAC gewährt wurden, kann Ihre Anfrage für die Rolle oder die Rollenbindung fehlschlagen Betrachten Sie beispielsweise die folgende Anfrage zur Rollenerstellung von einem Nutzer, dem die IAM-Berechtigungen container.pods.* und container.roles.create erteilt wurden:

kubectl create role allowed-to-view-pods --resource pods --verb list,get

Wenn dem Nutzer die Berechtigungen nur mit IAM gewährt wurden, kann der folgende Fehler auftreten:

Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "[e-mail]" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}

Um diese Einschränkung zu verringern, gewähren Sie dem Aufrufer die Berechtigungen in der Rolle mithilfe von RBAC anstelle von IAM.

Alternativ können Sie entweder RBAC oder IAM verwenden, um dem Aufrufer das Verb escalate, das Verb bind oder beides zuzuweisen. GKE empfiehlt diesen Ansatz jedoch nicht, da der Aufrufer jeder Rolle eine beliebige Berechtigung erteilen kann.

Nächste Schritte

• IAM-Richtlinien erstellen
• Google Groups for RBAC konfigurieren