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. Machen Sie sich vor dem Lesen dieses Leitfadens mit den Konzepten in unserer Übersicht vertraut.

Bei dieser Konfiguration können Nutzer das Connect-Gateway direkt verwenden und über ihre Google Cloud-Identität in der Cloud Console eine Verbindung zu registrierten Clustern außerhalb von Google Cloud herstellen, wie unter Bei der Cloud Console anmelden beschrieben.

Diese Einrichtung ermöglicht nur die Autorisierung 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.

Hinweis

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

    • Die neueste Version des Cloud SDK, einschließlich gcloud, dem Befehlszeilentool für die Interaktion mit Google Cloud.
    • kubectl

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

  • Achten Sie darauf, dass das gcloud-Befehlszeilentool zur Verwendung mit Ihrem Projekt initialisiert wurde.

  • In dieser Anleitung wird davon ausgegangen, dass sich roles/owner in Ihrem Projekt befindet. Wenn Sie kein Projektinhaber sind, benötigen Sie möglicherweise zusätzliche Berechtigungen, um einige Einrichtungsschritte auszuführen.

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 Cloud Console bei Clustern authentifizieren möchten, müssen Sie connectgateway.googleapis.com nicht aktivieren. Die verbleibenden APIs müssen jedoch aktiviert werden.

PROJECT_ID=example_project
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. Anthos-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 unter Cluster registrieren. GKE-Cluster müssen beim Connect Agent 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 hub 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

Nutzer und Dienstkonten benötigen die folgenden zusätzlichen Google Cloud-Rollen, um über das Gateway mit verbundenen Clustern zu interagieren, es sei denn, der Nutzer oder das Konto hat roles/owner im Projekt:

  • roles/gkehub.gatewayAdmin. Mit dieser Rolle kann ein Nutzer auf die Connect Gateway API zugreifen.
    • Wenn ein Nutzer nur Lesezugriff auf verbundene Cluster benötigt, kann stattdessen roles/gkehub.gatewayReader verwendet werden.
  • roles/gkehub.viewer. Mit dieser Rolle kann ein Nutzer Clusteranmeldedaten abrufen.

Sie weisen diese Rollen mit dem Befehl gcloud projects add-iam-policy-binding so zu:


# [PROJECT_ID] is the project's unique identifier.
# [ACCOUNT_ADDRESS] is an email address, which can belong to either a user account or a service account

PROJECT_ID=example_project

# MEMBER should be of the form `user|serviceAccount:$ACCOUNT_ADDRESS`, for example:
# MEMBER=user:foo@example.com
# MEMBER=serviceAccount:test@example-project.iam.gserviceaccount.com

MEMBER=user:foo@example.com

# GATEWAY_ROLE should be `roles/gkehub.gatewayAdmin` or `roles/gkehub.gatewayReader`.
GATEWAY_ROLE=roles/gkehub.gatewayAdmin

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

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 Cloud Console gewähren

Für Nutzer, die nur mit verbundenen Clustern über die Cloud Console interagieren möchten, sind folgende Rollen erforderlich:

  • roles/gkehub.viewer. Mit dieser Rolle kann der Nutzer die Cluster auf der GKE-Konsolenseite aufrufen.
  • roles/container.viewer. Mit dieser Rolle kann der Nutzer Containerressourcen in der Cloud Console aufrufen.

Richtlinien für die rollenbasierte Zugriffssteuerung (RBAC) konfigurieren

Schließlich muss der Kubernetes API-Server jedes Clusters in der Lage sein, kubectl-Befehle zu autorisieren, die das Gateway von Ihren angegebenen Nutzern und Dienstkonten aus erlaubt. Um dies zu gewährleisten, müssen Sie die RBAC-Richtlinien auf jedem Cluster aktualisieren, der über das Gateway zugänglich sein soll. Es gibt zwei Richtlinien, die Sie aktualisieren oder hinzufügen müssen:

  • Eine Identitätsrichtlinie, die den Connect-Agent autorisiert, Anfragen im Namen eines Nutzers an den Kubernetes API-Server zu senden. Das folgende Beispiel zeigt, wie Sie eine solche Richtlinie für einen Nutzer (foo@example.com) und ein Dienstkonto (test@example-project.iam.gserviceaccount.com) erstellen und anwenden, indem Sie die Richtliniendatei als /tmp/impersonate.yaml speichern und auf den Cluster anwenden, der dem aktuellen Kontext zugeordnet ist:
cat <<EOF > /tmp/impersonate.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
EOF
# Apply impersonation policy to the cluster.
kubectl apply -f /tmp/impersonate.yaml

Hierdurch wird jedoch nicht sichergestellt, dass die Anfrage selbst vom API-Server autorisiert wird. Dazu müssen Sie jedem Konto außerdem ausdrücklich die entsprechenden RBAC-Berechtigungen erteilen, um Kubernetes-Vorgänge auszuführen.

  • Eine Berechtigungsrichtlinie, die angibt, welche Berechtigungen der Nutzer auf dem Cluster hat. Das folgende Beispiel zeigt, wie Sie einem Nutzer und einem Dienstkonto cluster-admin-Berechtigungen für den Cluster gewähren. Die Richtliniendatei wird als /tmp/admin-permissions.yaml gespeichert und auf den Cluster angewendet, der dem aktuellen Kontext zugeordnet ist.
cat <<EOF > /tmp/admin-permission.yaml
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 permission policy to the cluster.
kubectl apply -f /tmp/admin-permission.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