Rollenbasierte Zugriffssteuerung

Diese Seite bietet eine Übersicht über das von Kubernetes bereitgestellte rollenbasierte Zugriffssteuerungssystem (Role-based Access Control, RBAC) und wie Sie Kubernetes RBAC in Google Kubernetes Engine (GKE) verwenden können.

Überblick

Kubernetes enthält einen integrierten RBAC-Mechanismus, mit dem Sie detaillierte und spezifische Berechtigungssätze konfigurieren können. Diese Berechtigungssätze definieren die Interaktionsmöglichkeiten eines bestimmten Google Cloud-Nutzers oder einer Gruppe von Nutzern in Bezug auf ein Kubernetes-Objekt im Cluster oder in einem bestimmten Namespace des Clusters.

Kubernetes RBAC ist standardmäßig aktiviert.

Vorbereitung

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

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone aus.

gcloud config verwenden

  • Geben Sie Ihre standardmäßige Projekt-ID an:
    gcloud config set project project-id
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Standardzone für Compute Engine fest:
    gcloud config set compute/zone compute-zone
  • Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:
    gcloud config set compute/region compute-region
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

Interaktion mit der Identitäts- und Zugriffsverwaltung

Sie können Cloud Identity and Access Management und Kubernetes RBAC verwenden, um den Zugriff auf den GKE-Cluster zu steuern:

  • Cloud IAM ist kein spezifisches Kubernetes-Produkt. Es bietet 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.

Cloud IAM und Kubernetes RBAC sind in GKE zu dem Zweck eingebunden, Nutzer zum Ausführen von Aktionen zu autorisieren, sofern sie laut 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.

Obwohl in fast allen Fällen Kubernetes RBAC anstelle von Cloud IAM verwendet werden kann, benötigen GKE-Nutzer mindestens die Cloud IAM-Berechtigung container.clusters.get in dem Projekt, das den Cluster enthält. Diese Berechtigung ist in der Rolle container.clusterViewer sowie in den anderen Rollen mit einer höheren Anzahl von 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 Cloud IAM oder Kubernetes RBAC bereitgestellt werden.

Voraussetzungen für die Verwendung von Kubernetes RBAC auf GKE-Clustern mit Version 1.11.x und niedriger

In GKE-Clustern mit GKE Version 1.11.x und niedriger ist Cloud IAM insofern eingeschränkt, als es dem Nutzer keine Berechtigung zum Erstellen eines Role- oder ClusterRole-Objekts von Kubernetes RBAC gewähren kann. Allerdings wird Nutzern durch die Cloud IAM-Rolle "Kubernetes Engine-Administrator" die Berechtigung zum Erstellen eines RoleBinding- oder -ClusterRoleBinding-Objekts von Kubernetes RBAC für beliebige Nutzer, einschließlich sich selbst, gewährt. Damit können Google Cloud-Nutzer an vordefinierte RBAC-Rollen gebunden werden.

Insbesondere werden Nutzern durch die vordefinierte RBAC-Rolle cluster-admin uneingeschränkte Berechtigungen im Cluster gewährt. Wenn Sie daher einem Nutzer beim Bootstrapping erlauben möchten, RBAC-Role- und -ClusterRole-Objekte zu erstellen, führen Sie folgenden Befehl aus und ersetzen user-account durch die Google Cloud-Log-in-E-Mail-Adresse des Zielnutzers.

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin \
  --user user-account

Google Groups for GKE

Früher konnten Rollen nur Google Cloud-Nutzerkonten oder Cloud IAM-Dienstkonten zugewiesen werden. Mit Google Groups for GKE (Beta) können Sie Mitgliedern von G Suite Google Groups Rollen zuzuweisen. Mit diesem Mechanismus werden die Nutzer und die Gruppen von Ihren G Suite-Administratoren komplett außerhalb von Kubernetes oder der Cloud Console verwaltet, sodass die Clusteradministratoren keine detaillierten Informationen über Ihre Nutzer benötigen. Ein weiterer Vorteil ist die Einbettung in Ihre bestehenden Methoden zur Verwaltung von Nutzerkonten, z. B. zum Sperren des Zugriffs für Personen, die Ihre Organisation verlassen.

Führen Sie die folgenden Aufgaben aus, um dieses Feature zu verwenden:

Anforderungen

Für die Verwendung von Google Groups für GKE gelten folgende Anforderungen:

  • Sie benötigen ein G Suite- oder Cloud Identity-Abo.

Google Groups für die Verwendung mit RBAC konfigurieren

Die Konfiguration des Clusters für die Verwendung dieses Features und die Syntax zum Referenzieren einer G Suite Google Group in Kubernetes RBAC wird in diesem Thema weiter unten noch erläutert. Zuerst müssen Sie Google Groups anhand der nachfolgenden Schritte einrichten:

  1. Erstellen Sie eine G Suite Google Group namens gke-security-groups@yourdomain.com in Ihrer Domain. Der Name der Gruppe muss genau gke-security-groups lauten. Sorgen Sie dafür, dass die Gruppe gke-security-groups die Berechtigung "Mitglieder ansehen" für "Gruppenmitglieder" hat. In diesem Artikel finden Sie ein Beispiel für die Einstellung in der G Suite-Admin-Konsole.

    Weitere Informationen zur Verwaltung von Gruppen in der G Suite finden Sie in der Google Groups-Hilfe.

  2. Erstellen Sie Gruppen (sofern noch nicht vorhanden), die Gruppen von Nutzern oder bestimmte Gruppen darstellen, die unterschiedliche Berechtigungen für die Cluster haben sollten. Jede Gruppe muss die Berechtigung "Mitglieder ansehen" für "Gruppenmitglieder" haben.

  3. Fügen Sie diese Gruppen (nicht die Nutzer) als Mitglieder von gke-security-groups@yourdomain.com hinzu.

Damit GKE weiß, ob ein bestimmter Nutzer zum Erstellen, Ändern oder Ansehen einer Clusterressource gemäß seiner Gruppenmitgliedschaft berechtigt ist, wird einerseits geprüft, ob der Nutzer Mitglied einer zugriffsberechtigten Gruppe ist, und andererseits, ob diese Gruppe ein direktes Mitglied der Gruppe gke-security-groups Ihrer Domain ist. Der Nutzer muss außerdem derselben Domain angehören wie die Gruppe und der Cluster. Dies bedeutet, dass die domainübergreifende Autorisierung mit diesem Feature nicht funktioniert.

Informationen zur Mitgliedschaft in G Suite Google Groups werden für kurze Zeit im Cache gespeichert. Es kann einige Minuten dauern, bis Änderungen an Gruppenmitgliedschaften an alle Cluster weitergegeben wurden. Zusätzlich zur Latenz aufgrund von Gruppenänderungen dauert das Standard-Caching von Nutzeranmeldedaten im Cluster etwa eine Stunde.

Cluster für die Verwendung von Google Groups for GKE konfigurieren

Nachdem der G Suite Google Groups-Administrator die Gruppen eingerichtet hat, erstellen Sie einen neuen Cluster mit dem Befehl gcloud. Fügen Sie dann das folgende Flag hinzu und ersetzen Sie den Wert durch Ihren eigenen Domainnamen: --security-group="gke-security-groups@yourdomain.com".

Hier sehen Sie ein Beispiel für den Befehl zum Erstellen eines Clusters:

gcloud beta container clusters create cluster-name \
  --security-group="gke-security-groups@yourdomain.com"

Jetzt können Sie Role-, ClusterRole-, RoleBinding- und ClusterRoleBinding-Objekte erstellen, die auf Ihre G Suite Google Groups verweisen.

Berechtigungen definieren und zuweisen

Zum Definieren der RBAC-Berechtigungen erstellen Sie die folgenden Arten von Kubernetes-Objekten:

  • ClusterRole oder Role: definiert einen Satz von Ressourcentypen und -vorgängen, der einem Nutzer bzw. einer Gruppe von Nutzern (ClusterRole) oder einem Namespace (Role) zugewiesen werden kann, gibt jedoch nicht den Nutzer oder die Gruppe von Nutzern an.
  • ClusterRoleBinding oder RoleBinding: weist einem Nutzer oder einer Gruppe von Nutzern ein ClusterRole- oder Role-Objekt zu. Ein ClusterRoleBinding-Objekt wird mit einem ClusterRole-Objekt verwendet und ein RoleBinding-Objekt entweder mit einem ClusterRole- oder einem Role-Objekt.

RBAC-Rollen sind rein additiv – es gibt keine "deny"-Regeln, die den Zugriff ablehnen. Wenn Sie Ihre RBAC-Rollen strukturieren, sollten Sie also vornehmlich darüber nachdenken, welchen Nutzern Zugriff auf Clusterressourcen gewährt werden sollte.

Berechtigungen mithilfe von Role- oder ClusterRole-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 den relevanten Namespace, den Ressourcentyp und die zulässigen Vorgänge für das Role-Objekt definieren. Das folgende Role-Objekt gewährt beispielsweise Lesezugriff (get, watch und list) für alle Pods im Namespace accounting:

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

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
  • Endpunkte, die keine Ressourcen sind, beispielsweise /healthz
  • 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
Cloud IAM-Dienstkonto User Automatisch generierte E-Mail-Adresse des Cloud IAM-Dienstkontos
Adresse einer G Suite Google Group (Beta) in einer bestätigten Domain Group E-Mail-Adresse einer Google Group, die selbst Mitglied der Google Group gke-security-groups@yourdomain.com ist

Mit dem folgenden RoleBinding-Objekt wird einem Nutzer, einem Kubernetes-Dienstkonto, einem Cloud IAM-Dienstkonto und einer Google Group 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: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# Cloud IAM service account
- kind: User
  name: test-account@test-project-123456.google.com.iam.gserviceaccount.com
# G Suite Google Group
- kind: Group
  name: accounting-group@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

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 Autorisierung der rollenbasierten Zugriffssteuerung verwenden.

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 für GKE verwenden, wird google groups in der Lognachricht angezeigt.

Fehlerbehebung bei der Einbindung von Google Groups

Mit der folgenden Anleitung können Sie Logs aufrufen, um zu prüfen, ob Ihre Cluster erfolgreich für die Verwendung von Google Groups in RBAC-Rollenbindungen konfiguriert wurden.

Voraussetzungen

Bevor Sie mit der Prüfung der Logs beginnen, müssen folgende Voraussetzungen erfüllt sein:

  • Sie haben mindestens eine Stunde lang nicht mit dem zu testenden Cluster interagiert (z. B. kubectl-Befehle ausgeführt). Die Authentifizierung wird eine Stunde lang im Cache gespeichert und die Anfrage muss protokolliert werden, wenn sie eingeht.
  • Sie sind Mitglied in mindestens einer der Gruppen in gke-security-groups. Dadurch wird gewährleistet, dass bestimmte Google Groups-Informationen in die Logs eingetragen werden.

Logs konfigurieren

So verwenden Sie Logs für die Fehlerbehebung in Google Groups mit RBAC:

  1. Aktivieren Sie das Datenzugriffs-Logging für Ihr Google Cloud-Projekt. So aktivieren Sie das Logging:

    1. Rufen Sie in der Cloud Console im Menü Cloud IAM die Seite Audit-Logs auf.

      Zur Audit-Logs-Seite

    2. Wählen Sie in der Tabelle Kubernetes Engine API aus.

    3. Wählen Sie im Menü Log-Typ Folgendes aus:

      • Administratortätigkeit
      • Daten lesen
      • Daten schreiben
    4. Klicken Sie auf Speichern.

    Weitere Informationen zum Aktivieren von Audit-Logging finden Sie in der Dokumentation zu den Cloud-Verwaltungstools unter Datenzugriffslogs mit der Cloud Console konfigurieren.

  2. Führen Sie einen Befehl mit kubectl im Cluster aus. Beispielsweise ganz einfach mit kubectl create ns helloworld.

  3. Geben Sie auf der Seite Loganzeige eine benutzerdefinierte Abfrage ein. Das geht so:

    1. Rufen Sie in der Cloud Console im Menü Logging die Seite Loganzeige auf.

      Loganzeige aufrufen

    2. Klicken Sie oben auf der Seite im Feld Abfragevorschau auf den Pfeil.

    3. Kopieren Sie im angezeigten Drop-down-Feld die folgende Abfrage und fügen Sie sie ein:

      resource.type="k8s_cluster"
      resource.labels.location="cluster-region"
      resource.labels.cluster_name="cluster-name"
      protoPayload.resourceName="authorization.k8s.io/v1beta1/subjectaccessreviews"
      protoPayload.response.spec.user="email-address"
      

      Dabei gilt:

      • cluster-region ist die Region oder Zone Ihres Clusters.
      • cluster-name ist der Name des Clusters.
      • email-address ist die registrierte E-Mail-Adresse Ihres Google-Kontos.
    4. Wählen Sie Abfrage ausführen aus. Sie sollten mindestens ein Ergebnis sehen. Ist dies nicht der Fall, versuchen Sie, den Zeitraum zu verlängern.

    5. Wählen Sie den Cluster aus, den Sie untersuchen möchten.

    6. Klicken Sie auf Verschachtelte Felder erweitern.

    7. Das Feld protoPayload.request.spec.group enthält die Gruppen, in denen folgende Bedingungen erfüllt sind:

      • Die Gruppen sind Mitglieder von gke-security-group.
      • Sie sind Mitglied der Gruppe.

      Diese Liste sollte mit den Gruppen übereinstimmen, in denen Sie Mitglied sind. Wenn keine Gruppen vorhanden sind, liegt möglicherweise ein Problem mit der Einrichtung der Gruppen vor.

  4. Stellen Sie das Datenzugriffs-Logging auf die vorherigen Einstellungen zurück, um weitere Gebühren zu vermeiden (falls gewünscht).

Beschränkungen

In den folgenden Abschnitten werden Interaktionen beschrieben, die bei der Arbeit mit Kubernetes RBAC nicht immer 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. Vor Kubernetes Version 1.14 haben sowohl system:authenticated als auch system:unauthenticated die ClusterRole-Objekte system:basic-user und system:discovery standardmäßig gewährt.

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.

Ab Kubernetes 1.14 erhalten anonyme Nutzer (system:unauthenticated) stattdessen das ClusterRole-Objekt system:basic-info-viewer, das Lesezugriff auf /healthz und /version APIs 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 my-iam-account@somedomain.com angezeigt:

    displayName: Some Domain IAM service account
    email: my-iam-account@somedomain.com
    etag: BwWWja0YfJA
    name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com
    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
    

Nächste Schritte