Connect-Gateway einrichten

Dieser Leitfaden richtet sich an Plattformadministratoren, die das Connect-Gateway für die Verwendung durch Nutzer und Dienstkonten ihres Projekts einrichten müssen. Diese Konfiguration ermöglicht Nutzern:

  • Mit der Google Cloud Console können Sie sich mit ihrer Google Cloud-Identität in registrierten Clustern außerhalb von Google Cloud anmelden.

  • Verwenden Sie kubectl, um über das Connect-Gateway auf Cluster zuzugreifen.

Diese Einrichtung ermöglicht nur die Authentifizierung von Nutzern und Diensten auf Grundlage ihrer individuellen IDs, nicht ihrer Mitgliedschaft in Google Groups. Informationen zum Einrichten der zusätzlichen Gruppenunterstützung finden Sie unter Connect-Gateway mit Google Groups einrichten.

Wenn Sie mit dem Connect-Gateway nicht vertraut sind, finden Sie in unserer Übersicht eine Erläuterung der grundlegenden Konzepte und der Funktionsweise.

Vorbereitung

  1. Prüfen Sie, ob die folgenden Befehlszeilentools installiert sind:

    • Die neueste Version der Google Cloud CLI, des Befehlszeilentools für die Interaktion mit Google Cloud.
    • kubectl zum Ausführen von Befehlen für Kubernetes-Cluster. Falls Sie kubectl installieren müssen, folgen Sie dieser Anleitung.

    Wenn Sie Cloud Shell als Shell-Umgebung für die Interaktion mit Google Cloud verwenden, sind diese Tools für Sie installiert.

  2. Initialisieren Sie entweder die gcloud CLI zur Verwendung mit Ihrem Projekt oder führen Sie die folgenden Befehle aus, um die gcloud CLI zu autorisieren und Ihr Projekt als Standard festzulegen:

    gcloud auth login
gcloud config set project PROJECT_ID

Erforderliche IAM-Rollen für die Einrichtung

In dieser Anleitung wird davon ausgegangen, dass Sie die Berechtigung roles/owner in Ihrem Projekt haben. Wenn Sie kein Projektinhaber sind, bitten Sie einen Projektinhaber, Ihnen weitere Berechtigungen für das Projekt zu erteilen, damit Sie die folgenden Aufgaben ausführen können:

  • Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable, die in der Rolle Service Usage-Administrator (roles/serviceusage.serviceUsageAdmin) enthalten ist. Ein Projektinhaber kann entweder eine benutzerdefinierte Rolle mit aktivierter Berechtigung serviceusage.services.enable erstellen oder Ihnen roles/serviceusage.serviceUsageAdmin so zuweisen:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/serviceusage.serviceUsageAdmin'

  • Wenn Sie Nutzern und Dienstkonten IAM-Berechtigungen erteilen möchten, damit sie das Connect-Gateway verwenden können, benötigen Sie die Rolle Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin), die eine der Projektinhaber mit folgendem Befehl gewähren kann:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/resourcemanager.projectIamAdmin'

APIs aktivieren

Aktivieren Sie die Connect-Gateway-API und die erforderlichen Abhängigkeits-APIs, um das Gateway Ihrem Projekt hinzuzufügen. Wenn sich Ihre Nutzer nur über die Google Cloud Console bei Clustern authentifizieren möchten, müssen Sie connectgateway.googleapis.com nicht aktivieren. Die anderen APIs müssen jedoch aktiviert werden.

gcloud services enable --project=PROJECT_ID  \
    connectgateway.googleapis.com \
    anthos.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com

Registrierte Cluster prüfen

Nur auf Cluster, die für Ihre Projektflotte registriert sind, kann über das Connect-Gateway zugegriffen werden. GKE-Cluster, die lokal und in anderen öffentlichen Clouds erstellt werden, werden bei der Erstellung automatisch registriert. GKE-Cluster in Google Cloud und angehängte Cluster müssen jedoch separat registriert werden. Wenn Sie einen Cluster registrieren müssen, folgen Sie der Anleitung in unseren Leitfäden für die Clusterregistrierung. GKE-Cluster müssen in der Flotte registriert sein, um das Gateway verwenden zu können.

Führen Sie den folgenden Befehl aus, um zu prüfen, ob Cluster registriert wurden:

gcloud container fleet memberships list

Sie sollten eine Liste aller registrierten Cluster sehen, wie in der folgenden Beispielausgabe gezeigt:

NAME         EXTERNAL_ID
cluster-1    0192893d-ee0d-11e9-9c03-42010a8001c1
cluster-2    f0e2ea35-ee0c-11e9-be79-42010a8400c2

Nutzern IAM-Rollen zuweisen

Der Zugriff auf Cluster wird durch die Identitäts- und Zugriffsverwaltung (IAM) gesteuert. Die erforderlichen IAM-Rollen für den Zugriff auf Cluster mit kubectl unterscheiden sich geringfügig von den Rollen für den Zugriff auf Cluster in der Google Cloud Console, wie in den folgenden Abschnitten erläutert.

Rollen für den Zugriff über kubectl gewähren

Nutzer und Dienstkonten benötigen mindestens die folgenden IAM-Rollen, um kubectl für die Interaktion mit Clustern über das Connect-Gateway zu verwenden, es sei denn, der Nutzer hat die Rolle roles/owner im Projekt:

  • roles/gkehub.gatewayAdmin: Mit dieser Rolle kann ein Nutzer auf die Connect-Gateway-API zugreifen, um den Cluster mithilfe von kubectl zu verwalten.

    • Wenn ein Nutzer nur Lesezugriff auf verbundene Cluster benötigt, können Sie stattdessen roles/gkehub.gatewayReader gewähren.

    • Wenn ein Nutzer Lese-/Schreibzugriff auf verbundene Cluster benötigt, können Sie roles/gkehub.gatewayEditor gewähren.

  • roles/gkehub.viewer: Mit dieser Rolle kann ein Nutzer Cluster-kubeconfigs abrufen.

Weitere Informationen zu den in diesen Rollen enthaltenen Berechtigungen finden Sie in der IAM-Dokumentation unter GKE-Hub-Rollen.

Sie können diese Rollen mit den folgenden Befehlen gewähren:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=GATEWAY_ROLE
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

wobei

  • MEMBER ist das Nutzer- oder Dienstkonto im Format user|serviceAccount:emailID. Beispiel:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com

  • GATEWAY_ROLE ist entweder roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader oder roles/gkehub.gatewayEditor.

Weitere Informationen zum Erteilen von IAM-Berechtigungen und -Rollen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen.

Rollen für den Zugriff über die Google Cloud Console gewähren

Nutzer, die mit Clustern außerhalb von Google Cloud über die Google Cloud Console interagieren möchten, benötigen mindestens die folgenden IAM-Rollen, um Cluster aufzurufen:

  • roles/container.viewer. Mit dieser Rolle können Nutzer die GKE-Clusterseite und andere Containerressourcen in der Google Cloud Console aufrufen. Weitere Informationen zu den Berechtigungen, die in dieser Rolle enthalten sind, finden Sie in der IAM-Dokumentation unter Kubernetes Engine-Rollen.

  • roles/gkehub.viewer. Mit dieser Rolle können Nutzer die Cluster außerhalb von Google Cloud in der Google Cloud Console aufrufen. Dies ist eine der für den kubectl-Zugriff erforderlichen Rollen. Wenn Sie diese Rolle bereits einem Nutzer zugewiesen haben, müssen Sie sie nicht noch einmal zuweisen. Weitere Informationen zu den Berechtigungen, die in dieser Rolle enthalten sind, finden Sie in der IAM-Dokumentation unter GKE-Hub-Rollen.

    Ersetzen Sie in den folgenden Befehlen PROJECT_ID durch die Projekt-ID des Flottenhostprojekts. Ersetzen Sie außerdem MEMBER durch die E-Mail-Adresse oder das Dienstkonto des Nutzers im Format user|serviceAccount:emailID. Beispiel:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

Weitere Informationen zum Zuweisen von IAM-Rollen finden Sie in der IAM-Dokumentation unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

RBAC-Autorisierung konfigurieren

Der Kubernetes API-Server jedes Clusters muss Anfragen von der Google Cloud Console oder von kubectl-Befehlen autorisieren, die vom Connect-Gateway Ihrer angegebenen Nutzer und Dienstkonten stammen. Um dies zu gewährleisten, müssen Sie die Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) auf jedem Cluster aktualisieren, der über das Gateway zugänglich sein soll. Fügen Sie die folgenden Richtlinien hinzu oder aktualisieren Sie sie:

  • Eine Identitätsrichtlinie, die den Connect-Agent autorisiert, Anfragen im Namen eines Nutzers an den Kubernetes API-Server zu senden.
  • Eine Berechtigungsrichtlinie, die angibt, welche Berechtigungen der Nutzer auf dem Cluster hat. Dies kann eine Rolle auf Clusterebene wie clusterrole/cluster-admin oder clusterrole/cloud-console-reader oder eine Rolle auf Namespace-Ebene wie role/default/pod-reader sein.

(Optional) cloud-console-reader-Rolle erstellen

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 erstellen, die die Mindestberechtigungen zum Aufrufen der Knoten, nichtflüchtigen Volumes, Pods und Speicherklassen des Clusters enthält. Um diese Berechtigungen zu definieren, erstellen Sie im Cluster eine ClusterRole-RBAC-Ressource, cloud-console-reader.

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 die ClusterRole-cloud-console-reader 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

Sie können diese Rolle dann Nutzern beim Einrichten Ihrer Berechtigungsrichtlinien zuweisen, wie im nächsten Abschnitt beschrieben.

Erforderliche RBAC-Richtlinien erstellen und anwenden

Im Folgenden wird gezeigt, wie Sie die erforderlichen RBAC-Richtlinien erstellen und anwenden. Am einfachsten ist es, wenn Sie über die gcloud CLI die entsprechenden Richtlinien generieren und anwenden. Alternativ können Sie auch eine RBAC-Richtliniendatei erstellen und mit kubectl anwenden.

gcloud

Führen Sie den folgenden Befehl aus, um die Richtlinien mit der gcloud CLI zu generieren und auf Ihren ausgewählten Cluster anzuwenden:

gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply

Dabei gilt:

  • MEMBERSHIP_NAME: der Name, der zur eindeutigen Darstellung des Clusters in seiner Flotte verwendet wird. Informationen zum Prüfen des Mitgliedsnamens Ihres Clusters finden Sie unter Status der Flottenmitgliedschaft abrufen.
  • ROLE: die Kubernetes-Rolle, die Sie den Nutzern im Cluster zuweisen möchten, z. B. clusterrole/cluster-admin, clusterrole/cloud-console-reader oder role/mynamespace/namespace-reader. Diese Rolle muss bereits vorhanden sein, bevor Sie den Befehl ausführen.
  • USERS: Die E-Mail-Adressen der Nutzer (Nutzerkonten oder Dienstkonten), denen Sie Berechtigungen erteilen möchten, als durch Kommas getrennte Liste. Beispiel: --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com.
  • PROJECT_ID: die ID des Projekts, in dem der Cluster registriert ist.
  • KUBECONFIG_PATH: der lokale Dateipfad, in dem die kubeconfig-Datei mit einem Eintrag für den Cluster gespeichert ist. In den meisten Fällen ist dies $HOME/.kube/config.

  • KUBECONFIG_CONTEXT ist der Clusterkontext des Clusters, wie er in der Datei „kubeconfig” angezeigt wird. Sie können den aktuellen Kontext über die Befehlszeile abrufen, indem Sie kubectl config current-context ausführen. Unabhängig davon, ob Sie den aktuellen Kontext verwenden oder nicht, achten Sie darauf, dass er für den Zugriff auf den Cluster funktioniert. Führen Sie dazu einen einfachen Befehl wie den folgenden aus:

    kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT

Nach der Ausführung von gcloud container fleet memberships generate-gateway-rbac wird am Ende der Ausgabe etwa Folgendes angezeigt:

connectgateway_example-project-12345_global_example-membership-name

Dies ist der Kontext für den Zugriff auf den Cluster über das Connect-Gateway.

Weitere Informationen zum Befehl generate-gateway-rbac finden Sie im Referenzhandbuch für die gcloud-Befehlszeile.

Wenn beim Ausführen dieses Befehls ein Fehler wie ERROR: (gcloud.container.hub.memberships) Invalid choice: 'generate-gateway-rbac' angezeigt wird, aktualisieren Sie die Google Cloud CLI. Folgen Sie dazu der Aktualisierungsanleitung.

kubectl

Das folgende Beispiel zeigt, wie Sie geeignete Richtlinien für einen Nutzer (foo@example.com) und ein Dienstkonto (test@example-project.iam.gserviceaccount.com) erstellen, indem Sie ihnen sowohl cluster-admin-Berechtigungen für den Cluster geben als auch die Richtliniendatei als /tmp/gateway-rbac.yaml speichern. Die Richtlinien werden dann auf den Cluster angewendet, der dem aktuellen Kontext zugeordnet ist:

cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-impersonate
rules:
- apiGroups:
  - ""
  resourceNames:
  - foo@example.com
  - test@example-project.iam.gserviceaccount.com
  resources:
  - users
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-impersonate
roleRef:
  kind: ClusterRole
  name: gateway-impersonate
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: connect-agent-sa
  namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin
subjects:
- kind: User
  name: foo@example.com
- kind: User
  name: test@example-project.iam.gserviceaccount.com
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply policies to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH  -f /tmp/gateway-rbac.yaml

Weitere Informationen zum Angeben von RBAC-Berechtigungen finden Sie unter RBAC-Autorisierung verwenden.

Unterstützung durch VPC Service Controls

VPC Service Controls bietet eine zusätzliche Sicherheitsebene für Google Cloud-Dienste, die unabhängig von der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) ist. IAM ermöglicht eine detaillierte identitätsbasierte Zugriffssteuerung. VPC Service Controls hingegen ermöglicht eine breitere kontextbasierte Perimetersicherheit, einschließlich der Kontrolle ausgehender Datenübertragungen im gesamten Perimeter. Sie können beispielsweise angeben, dass nur bestimmte Projekte auf Ihre BigQuery-Daten zugreifen können. Weitere Informationen zum Schutz von Daten mit VPC Service Controls finden Sie hier.

Sie können VPC Service Controls mit dem Connect-Gateway für zusätzliche Datensicherheit verwenden, wenn Sie dafür sorgen, dass innerhalb des angegebenen Dienstperimeters auf die erforderlichen APIs zur Verwendung des Gateways zugegriffen werden kann.

Nächste Schritte