Rollenbasierte Zugriffssteuerung

Auf dieser Seite erhalten Sie eine Übersicht über das von Kubernetes bereitgestellte System für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC). Außerdem erfahren Sie, wie Sie Kubernetes RBAC in Google Kubernetes Engine verwenden können.

Übersicht

Kubernetes bietet einen integrierten Mechanismus zur rollenbasierten Zugriffssteuerung namens RBAC, mit dem Sie detaillierte und spezifische Berechtigungen konfigurieren können. Anhand dieser Berechtigungen wird festgelegt, welche Interaktionsmöglichkeiten ein bestimmter Google Cloud-Nutzer oder eine bestimmte Gruppe von Nutzern in Bezug auf ein Kubernetes-Objekt im Cluster oder in einem bestimmten Namespace des Clusters hat.

Kubernetes RBAC ist standardmäßig aktiviert.

Vorbereitung

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

Richten Sie die Standardeinstellungen für gcloud mithilfe einer der folgenden Methoden ein:

  • Verwenden Sie gcloud init, wenn Sie eine Einführung in die Standardeinstellungen erhalten möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region im Einzelnen festzulegen.

gcloud init verwenden

  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 der Befehl einen Browser startet:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud die Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene Konfiguration 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, die es Ihnen ermöglicht, Rollen (spezifische Berechtigungen) für jedes Objekt oder jeden Objekttyp im Cluster zu erstellen und zu gewähren.

Cloud IAM und Kubernetes RBAC sind in GKE eingebunden. Sie haben den Zweck, Nutzer zum Ausführen von Aktionen zu autorisieren, wenn diese unter 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.

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 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 für den 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. Ersetzen Sie user-account dabei 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

beta

Früher konnten Rollen nur Google Cloud-Nutzerkonten oder Cloud IAM-Dienstkonten zugewiesen werden. Google Groups for GKE (Beta) ermöglicht Ihnen nun, 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.

Zur Verwendung dieses Features konfigurieren Sie G Suite Google Groups, erstellen einen Cluster mit dem aktivierten Feature und verknüpfen diese Google Groups dann mit Sätzen von Clusterberechtigungen.

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 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 über die Berechtigung "Mitglieder aufrufen" für "Gruppenmitglieder" verfügt. 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.

  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 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.

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 die folgende Option 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 festlegen 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 darüber nachdenken, welchen Nutzern Zugriff auf Clusterressourcen gewährt werden sollte.

Berechtigungen mithilfe von Rollen oder ClusterRoles definieren

Sie definieren Berechtigungen in einem Role- oder ClusterRole-Objekt. Ein Role-Objekt definiert den Zugriff auf Ressourcen in genau einem Namespace; ein ClusterRole-Objekt hingegen legt den Zugriff auf Ressourcen im gesamten Cluster fest.

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 werden als subjects bezeichnet und können Folgendes sein:

Subject-Typ Wert für kind Wert für name
Google Cloud-Nutzerkonto User Registrierte Google Cloud-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 Using RBAC Authorization.

Vorsichtsmaßnahmen

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 gespeichert. Alle anderen Anfragen fallen in die Gruppe system:unauthenticated. 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

Dieser Fehler kann auftreten, wenn die VM-Instanz den Bereich "userinfo-email" nicht enthält. Angenommen, die VM umfasst den Bereich "cloud-platform", jedoch nicht den Bereich "userinfo-email". Wenn die VM in diesem Fall ein Zugriffstoken empfängt, ordnet Google Cloud dieses Token dem Bereich "cloud-platform" zu. 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.

Damit die Authentifizierung erfolgreich verläuft, 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 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
        
  2. Erstellen Sie eine Rollenbindung mithilfe der eindeutigen ID:

        kubectl create clusterrolebinding clusterrolebinding-name \
          --clusterrole cluster-admin \
          --user unique-id
        

Nächste Schritte