Nutzerzugriff für GKE Identity Service einrichten

Dieses Dokument richtet sich an Clusteradministratoren, die bereits Cluster für den GKE Identity Service gemäß der Anleitung unter Cluster für GKE Identity Service auf Flottenebene konfigurieren oder Cluster für GKE Identity Service mit OIDC konfigurieren konfiguriert haben. Dort wird beschrieben, wie Sie den Zugriff auf Ihren konfigurierten Cluster für die Entwickler Ihrer Organisation und andere Clusternutzer einrichten und einschränken.

Zugriff für Nutzeranmeldung einrichten

Nachdem Sie einen Cluster konfiguriert haben, müssen Sie eine Anmeldekonfigurationsdatei generieren und an Clusternutzer verteilen. Mit dieser Datei können sich Nutzer über die Befehlszeile bei Ihrem ausgewählten Anbieter im Cluster anmelden, wie unter Mit GKE Identity Service auf Cluster zugreifen beschrieben.

Nur mit OIDC-Anbietern können sich Nutzer auch ohne Anmeldungsdatei über die Google Cloud Console im Cluster anmelden, wie unter Mit Clustern über die Google Cloud Console arbeiten beschrieben.

Anmeldekonfiguration generieren

Console

(nur Einrichtung auf Flottenebene)

Kopieren Sie den angezeigten gcloud-Befehl und führen Sie ihn aus, um die Datei zu generieren.

gcloud

Wenn Sie den Cluster über die gcloud-Befehlszeile konfiguriert haben oder die Datei noch einmal generieren müssen, generieren Sie die Datei mit dem folgenden Befehl:

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

Dabei ist KUBECONFIG der Pfad zur kubeconfig-Datei für den Cluster. Wenn die kubeconfig mehrere Kontexte enthält, wird der aktuelle Kontext verwendet. Möglicherweise müssen Sie den aktuellen Kontext auf den richtigen Cluster zurücksetzen, bevor Sie den Befehl ausführen.

Ausführliche Referenzinformationen zu diesem Befehl, einschließlich zusätzlicher optionaler Parameter, finden Sie in der Google Cloud CLI-Referenz.

Der Standardname für die Anmeldekonfigurationsdatei ist kubectl-anthos-config.yaml. Dies ist der Name, den das Google Cloud CLI erwartet, wenn Sie sich mit der Datei anmelden. Wenn Sie einen nicht standardmäßigen Namen ändern möchten, lesen Sie den entsprechenden Abschnitt unter Anmeldekonfiguration verteilen weiter unten.

Informationen zur Fehlerbehebung im Zusammenhang mit dem Nutzerzugriff finden Sie unter Probleme mit dem Nutzerzugriff beheben.

Anmeldekonfiguration verteilen

Im Folgenden sind einige mögliche Ansätze zum Verteilen der Konfigurationsdatei aufgeführt:

• Hosten Sie die Datei unter einer zugänglichen URL. Nutzer können diesen Speicherort mit dem Flag --login-config angeben, wenn sie gcloud anthos auth login ausführen, wodurch das Google Cloud CLI die Datei abrufen kann.

  Durch Hosten der Datei auf einem sicheren Host. Weitere Informationen zur Verwendung von PEM-Zertifikaten für sicheren HTTPS-Zugriff finden Sie im Flag --login-config-cert der gcloud CLI.

• Stellen Sie die Datei für jeden Nutzer manuell bereit und geben Sie an, wo sie auf ihrem lokalen Computer gespeichert werden soll. Das Google Cloud CLI erwartet die Datei an einem für das Betriebssystem spezifischen Standardspeicherort. Wenn der Name oder Speicherort der Datei nicht standardmäßig ist, müssen Ihre Nutzer den Speicherort der Konfigurationsdatei mit dem Flag --login-config angeben, wenn Befehle für den Cluster ausgeführt werden. Eine Anleitung zum Speichern der Datei für Nutzer finden Sie unter Mit dem GKE Identity Service auf Cluster zugreifen.

• Übertragen Sie mit Ihren internen Tools die Konfigurationsdatei für die Authentifizierung per Push auf den Computer jedes Nutzers. Die Google Cloud CLI erwartet, dass die Datei je nach Nutzerbetriebssystem an folgenden Speicherorten gefunden wird:

  Linux

  $HOME/.config/google/anthos/kubectl-anthos-config.yaml

  macOS

  $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

  Windows

  %APPDATA%\google\anthos\kubectl-anthos-config.yaml

Nutzeranmeldezugriff über ein alternatives Authentifizierungsverfahren einrichten

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Anstatt die Konfigurationsdatei an alle Nutzer zu verteilen, können Sie einen Nutzeranmeldezugriff über ein alternatives Authentifizierungsverfahren einrichten. Nutzer können sich direkt auf dem GKE Identity Service-Server mit einem voll qualifizierten Domainnamen (FQDN) authentifizieren. Für SAML-Anbieter wird der Nutzeranmeldungszugriff nur über dieses alternative Authentifizierungsverfahren unterstützt.

Hinweis: Dieser alternative Authentifizierungsprozess wird für GKE on VMware und GKE on Bare Metal ab Version 1.28 unterstützt. Die Befehlszeilenversion gcloud, auf die Sie ein Upgrade ausführen müssen, ist 456.0.0.

FQDN für Nutzer freigeben

Anstelle einer Konfigurationsdatei können Clusteradministratoren den FQDN ihres GKE Identity Service-Servers für Nutzer freigeben. Nutzer können diesen FQDN verwenden, um sich beim Cluster anzumelden. Die Server-URL des GKE Identity Service wird in einem der folgenden Formate bereitgestellt:

• https://CLUSTER-SERVER-NAME.com
• CLUSTER-SERVER-NAME.com

Nutzeranmeldung mithilfe vertrauenswürdiger SNI-Zertifikate

SNI-Zertifikate vereinfachen den Clusterzugriff, da sie vertrauenswürdige Zertifikate nutzen, die bereits auf Unternehmensgeräten vorhanden sind. Administratoren verwenden dieses Zertifikat bei der Clustererstellung. Als Nutzer müssen Sie den von Ihrem Administrator bereitgestellten FQDN verwenden, um sich beim Cluster anzumelden. Alternativ können Sie eine sichere kubeconfig-Datei verwenden, in der das Token nach erfolgreicher Authentifizierung gespeichert wird.

Prüfen Sie vor dem Ausführen des folgenden Befehls, ob das vom GKE Identity Service-Server verwendete Zertifikat auf dem Gerät, auf dem die Nutzeranmeldung ausgeführt wird, als vertrauenswürdig eingestuft wird.

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE

Ersetzen Sie Folgendes:

• APISERVER_URL: FQDN des GKE Identity Service-Servers.
• OUTPUT_FILE: Verwenden Sie dieses Flag, wenn sich die Datei kubeconfig an einem anderen Speicherort als dem Standardspeicherort befindet. Wenn dieses Flag weggelassen wird, werden der Datei kubeconfig am Standardspeicherort Authentifizierungstokens hinzugefügt. Beispiel: --kubeconfig /path/to/custom.kubeconfig.

Nutzeranmeldungszugriff mit von der Zertifizierungsstelle ausgestellten Clusterzertifikaten

Wenn Sie als Nutzer kein vertrauenswürdiges SNI-Zertifikat auf Clusterebene verwenden, wird das vom Identitätsdienst verwendete Zertifikat von der Zertifizierungsstelle des Clusters ausgestellt. Administratoren verteilen dieses CA-Zertifikat an Nutzer. Führen Sie den folgenden Befehl mit dem CA-Zertifikat des Clusters aus, um sich im Cluster anzumelden:

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE

Hinweis: Wir empfehlen, das CA-Zertifikat auf ihren Geräten und in ihren Browsern als vertrauenswürdig einzustufen. Folgen Sie dazu der gerätespezifischen Anleitung. Dies ist eine einmalige Aktivität. Sobald das CA-Zertifikat vertrauenswürdig ist, können Sie sich im Cluster anmelden, ohne im Befehl das Argument --login-config-cert anzugeben.

Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) einrichten

Die Authentifizierung wird häufig mit der rollenbasierten Zugriffssteuerung von Kubernetes (Role-based Access Control, RBAC) kombiniert, um für authentifizierte Nutzer und Dienstkonten eine detailliertere Zugriffssteuerung zu ermöglichen. Es wird empfohlen, nach Möglichkeit RBAC-Richtlinien zu erstellen, die Gruppennamen anstelle von Nutzerkennungen verwenden. Wenn Sie die RBAC-Richtlinien explizit mit Gruppen verknüpfen, können Sie Nutzerzugriffsberechtigungen vollständig mit Ihrem Identitätsanbieter verwalten. Dann muss der Cluster nicht jedes Mal aktualisiert werden, wenn sich die Nutzerberechtigungen ändern. Wenn Sie die Zugriffssteuerung basierend auf der Mitgliedschaft von Sicherheitsgruppen mit OIDC konfigurieren möchten, muss der GKE Identity Service so eingerichtet sein, dass er das Abrufen von Informationen zur Gruppenmitgliedschaft von Ihrem Identitätsanbieter unterstützt.

Wenn Sie beispielsweise bestimmten authentifizierten Nutzern Zugriff auf die Pods des Clusters gewähren möchten, erstellen Sie eine ClusterRole, die Zugriff auf diese Ressourcen gewährt. Hier ein Beispiel:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["pods"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Anschließend erstellen Sie eine entsprechende ClusterRoleBinding, um den jeweiligen Nutzern die Berechtigungen in der ClusterRole zu gewähren; in diesem Fall Mitgliedern der Sicherheitsgruppe us-east1-cluster-admins und dem Nutzer mit der ID u98523-4509823:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-admins
subjects:
  # Grants anyone in the "us-east1-cluster-admins" group
  # read access to Pods in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case-sensitive
  apiGroup: rbac.authorization.k8s.io
  # Grants this specific user read access to Pods in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Hinweis: Wenn Ihr Identitätsanbieter einen Gruppennamen zurückgibt, der doppelte umgekehrte Schrägstriche enthält, sollten Sie einen der umgekehrten Schrägstriche weglassen, wenn Sie in der ClusterRoleBindingRessource auf den Gruppennamen verweisen. Wenn Sie beispielsweise eine Gruppe mit dem Namen corp\\my-group erstellt haben, verweisen Sie in der ClusterRoleBinding-Ressource mit corp\my-group darauf. Dies liegt daran, dass das erste umgekehrte Schrägstrich als Escape-Zeichen behandelt wird.

Im folgenden Beispiel gewährt dieser ClusterRoleBinding der entsprechenden Gruppe mit der ID 12345678-BBBb-cCCCC-0000-123456789012 Berechtigungen in der ClusterRole. Beachten Sie, dass diese Einstellung nur für Azure AD-Anbieter relevant und für Google Distributed Cloud Virtual für Bare-Metal-Cluster verfügbar ist.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
  # Retrieves group information for the group ID mentioned
- kind: Group
  name: 12345678-BBBb-cCCCC-0000-123456789012
  apiGroup: rbac.authorization.k8s.io

Weitere Informationen zur Verwendung von RBAC finden Sie unter Rollenbasierte Zugriffssteuerung konfigurieren und RBAC-Autorisierung verwenden.

RBAC-Rolle für den Zugriff auf die Google Cloud Console erstellen

Nutzer, die über OIDC-Anbieter authentifiziert wurden, können sich über die Google Cloud Console und die Befehlszeile in Clustern anmelden.

Authentifizierte Nutzer, die in der Google Cloud Console auf die Ressourcen eines Clusters zugreifen möchten, benötigen dafür die entsprechenden Kubernetes-Berechtigungen. Wenn Sie diesen Nutzern keine umfassenderen Berechtigungen gewähren möchten, z. B. die eines Clusteradministrators, können Sie eine benutzerdefinierte RBAC-Rolle mit den Mindestberechtigungen zum Ansehen der Knoten, nichtflüchtigen Volumes, Pods und Speicherklassen des Clusters erstellen. Sie können diese Berechtigungen definieren, indem Sie im Cluster die RBAC-Ressource cloud-console-reader erstellen.ClusterRole

cloud-console-reader gewährt den Nutzern der Ressource die Berechtigungen get, list und watch für die Knoten, nichtflüchtigen Volumes, Pods und Speicherklassen des Clusters, die das Aufrufen von Details zu diesen Ressourcen ermöglichen.

kubectl

Führen Sie den folgenden Befehl aus, um den cloud-console-reader ClusterRole zu erstellen und auf den Cluster anzuwenden:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

Anschließend können Sie Nutzern diese ClusterRole beim Einrichten Ihrer Berechtigungsrichtlinien zuweisen, wie im vorherigen Abschnitt beschrieben. Beachten Sie, dass Nutzer außerdem IAM-Berechtigungen benötigen, um Cluster in der Google Cloud Console anzusehen.