Rollenbasierte Zugriffssteuerung konfigurieren

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.

Übersicht

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

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project PROJECT_ID
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest:
    gcloud config set compute/zone COMPUTE_ZONE
  • Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Compute-Standardregion 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 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.

IAM und Kubernetes RBAC sind in GKE eingebunden, um 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.

Obwohl in fast allen Fällen Kubernetes RBAC anstelle von IAM verwendet werden kann, benötigen GKE-Nutzer mindestens die 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 IAM oder Kubernetes RBAC bereitgestellt werden.

Google Groups for GKE

Früher konnten Rollen nur Google Cloud-Nutzerkonten oder IAM-Dienstkonten zugewiesen werden. Mit Google Groups for GKE (Beta) können Sie Mitgliedern von Google Groups for Business Rollen zuweisen. Mit diesem Mechanismus werden die Nutzer und die Gruppen von Ihren Google Workspace-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 Google Workspace- 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 Google-Gruppe in Kubernetes RBAC wird in diesem Thema weiter unten erläutert. Zuerst müssen Sie Google Groups anhand der nachfolgenden Schritte einrichten:

  1. Erstellen Sie eine Google Gruppe 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 Einstellungen in der Admin-Konsole von Google Workspace.

    Weitere Informationen zur Verwaltung von Gruppen in Google Workspace 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.

Informationen zur Google Groups-Mitgliedschaft 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 Google Groups-Administrator die Gruppen eingerichtet hat, erstellen Sie mit dem Befehl gcloud einen neuen Cluster. Fügen Sie das Flag --security-group="gke-security-groups@yourdomain.com" hinzu und ersetzen Sie den Wert durch Ihren eigenen Domainnamen.

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 Google-Gruppen 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
  • 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 Groups-Adresse (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 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: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: test-account@test-project-123456.google.com.iam.gserviceaccount.com
# 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 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 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ü 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.

      Zur Loganzeige

    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:public-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