Connect-Gateway mit Drittanbieteridentitäten einrichten

Dieser Leitfaden richtet sich an Plattformadministratoren, die das Connect-Gateway in einem Projekt einrichten müssen, das Nutzer enthält, die keine Google-Identitäten haben und nicht zu Google Workspace gehören. In diesem Leitfaden werden diese Identitäten als „Drittanbieteridentitäten“ bezeichnet. Bevor Sie diesen Leitfaden lesen, sollten Sie mit den Konzepten in der Connect-Gateway-Übersicht vertraut sein. Informationen zum Autorisieren einzelner Google-Konten finden Sie unter Connect-Gateway einrichten. Informationen zur Unterstützung von Google Groups finden Sie unter Connect-Gateway mit Google Groups einrichten.

Bei der Einrichtung in diesem Leitfaden können sich Nutzer mit der Google Cloud CLI, dem Connect-Gateway und der Google Cloud Console in Flottenclustern anmelden.

Unterstützte Clustertypen

Sie können die Zugriffssteuerung mit Drittanbieteridentitäten über das Connect-Gateway für die folgenden registrierten Clustertypen einrichten:

• GKE-Cluster (alle unterstützten Versionen)
• Google Distributed Cloud auf VMware und Bare Metal (Version 1.13 und höher).
• GKE on AWS und GKE on Azure (Version 1.25 und höher)
• Angehängte Cluster (Version 1.16 und höher).

Wenn Sie lokale Cluster aktualisieren müssen, um diese Funktion zu verwenden, lesen Sie die Artikel Cluster für VMware aktualisieren und Cluster auf Bare-Metal aktualisieren.

Wenn Sie einen Anwendungsfall für GKE-Clusterumgebungen haben, die nicht oben aufgeführt sind, wenden Sie sich bitte an Cloud Customer Care oder das Connect-Gateway-Team.

Funktionsweise

Wie in der Übersicht beschrieben, verwenden Nutzer möglicherweise Identitätsanbieter, die nicht Google Workspace oder Cloud Identity sind. Mit der Mitarbeiteridentitätsföderation können Nutzer über ihre Drittanbieter-Identitätsanbieter wie Okta oder Azure Active Directory über das Connect-Gateway auf ihre Cluster zugreifen. Im Gegensatz zu Google-Konten werden Drittanbieter-Nutzer durch ein IAM-Hauptkonto (Identity and Access Management) im folgenden Format dargestellt:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE

• WORKFORCE_POOL_ID ist der Name des Personalpools, der den entsprechenden Drittpartei-Identitätsanbieter enthält.

• Die SUBJECT_VALUE ist die Zuordnung der Drittanbieteridentität zu einem Google-Subjekt.

Bei Drittanbietergruppen hat das IAM-Hauptkonto das folgende Format:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_VALUE

Das folgende Diagramm zeigt einen typischen Ablauf für einen Drittanbieter, der sich bei einem Cluster authentifiziert und Befehle für den Cluster ausführt, wobei dieser Dienst aktiviert ist. Damit dieser Ablauf erfolgreich ist, muss im Cluster eine Richtlinie für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) für den Nutzer oder eine Gruppe angewendet werden.

Für einzelne Nutzer muss im Cluster eine RBAC-Richtlinie vorhanden sein, in der der vollständige IAM-Hauptkontoname des Nutzers verwendet wird.

Wenn Sie die Gruppenfunktion verwenden, muss im Cluster eine RBAC-Richtlinie mit dem vollständigen IAM-Hauptkontonamen für eine Gruppe vorhanden sein, die:

1. den Nutzer [e-mail] als Mitglied enthält.

2. Ist in einer Zuordnung für einen Identitätsanbieter in einem Personalpool enthalten, der sich in der Google Cloud-Organisation von Alice befindet.

Hinweis: GKE Identity Service muss konfiguriert sein, damit Gruppen-Funktionen von Drittanbietern auf Flottenmitgliedsclustern außerhalb von Google Cloudfunktionieren.

1. Der Nutzer [e-mail] meldet sich mit seiner Drittanbieteridentität in gcloud an. Dazu verwendet er die browserbasierte Drittanbieteranmeldung. Wenn der Nutzer den Cluster über die Befehlszeile verwenden möchte, ruft er das Cluster-Gateway kubeconfig ab, wie unter Connect-Gateway verwenden beschrieben.
2. Der Nutzer sendet eine Anfrage, indem er einen kubectl-Befehl ausführt oder die Google Kubernetes Engine-Seiten Arbeitslasten oder Objektbrowser in der Google Cloud -Konsole öffnet.
3. Die Anfrage wird vom Connect-Gateway empfangen, das die Drittanbieter-Authentifizierung mithilfe der Workforce Identity-Föderation verarbeitet.
4. Das Connect-Gateway führt eine Autorisierungsprüfung mit IAM durch.
5. Der Connect-Dienst leitet die Anfrage an den auf dem Cluster ausgeführten Connect Agent weiter. Die Anfrage wird zusammen mit den Anmeldedaten des Nutzers zur Authentifizierung und Autorisierung im Cluster bereitgestellt.
6. Der Connect Agent leitet die Anfrage an den Kubernetes API-Server weiter.
7. Der Kubernetes API-Server leitet die Anfrage an GKE Identity Service weiter, der die Anfrage validiert.
8. GKE Identity Service gibt die Nutzer- und Gruppeninformationen von Drittanbietern an den Kubernetes API-Server zurück. Der Kubernetes API-Server kann diese Informationen dann dazu verwenden, die Anfrage basierend auf den konfigurierten RBAC-Richtlinien des Clusters zu autorisieren.

Hinweis

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

  • Die neueste Version der Google Cloud CLI, dem Befehlszeilentool für die Interaktion mit Google Cloud.
  • Das Kubernetes-Befehlszeilentool kubectl zur Interaktion mit Ihren Clustern.

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

• Achten Sie darauf, dass die gcloud CLI für die 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.

• Bei Clustern außerhalb von Google Cloudmuss GKE Identity Service Google APIs aus Ihrem Cluster aufrufen, um die Authentifizierung abzuschließen. Prüfen Sie, ob Ihre Netzwerkrichtlinie ausgehenden Traffic über einen Proxy erfordert.

Drittanbieter-Identitätsattributzuordnungen mit Workforce Identity einrichten

Achten Sie darauf, dass für Ihre Google Cloud -Organisation ein Personalpool und ein Identitätsanbieter eingerichtet sind. Folgen Sie dazu der Anleitung für Ihren Identitätsanbieter:

• Azure AD
• Okta
• Anderes OIDC oder SAML 2.0

Hinweis: Für jeden Identitätsanbieter gilt ein Limit für die Attributzuordnung von 4 Kilobyte, das auch Gruppen umfasst.

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 verbleibenden APIs müssen jedoch aktiviert werden.

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

Hinweis:

Wenn Sie kein Projektinhaber sind, müssen Sie die Berechtigung serviceusage.services.enable erhalten, bevor Sie APIs für Ihr Projekt aktivieren können.

GKE Identity Service einrichten

Die Drittanbieter-Identitätsunterstützungsfunktion des Connect-Gateways verwendet GKE Identity Service, um Informationen zur Gruppenmitgliedschaft von Google abzurufen. Weitere Informationen zu GKE Identity Service finden Sie unter Einführung in GKE Identity Service.

Wenn Sie GKE-Cluster mit dem Gateway verwenden, müssen Sie GKE Identity Service nicht einrichten, um die Drittanbieter-Identitätsunterstützung verwenden zu können. Folgen Sie stattdessen der Anleitung unter Google Groups for RBAC konfigurieren und fahren Sie mit IAM-Rollen gewähren fort, um Clustern über das Gateway Zugriff zu gewähren.

Wenn Sie in GKE angehängte Cluster mit dem Gateway verwenden, ist GKE Identity Service für die Drittanbieter-Identitätsunterstützung nicht erforderlich. Folgen Sie der Anleitung für den ausgewählten Clustertyp, um die Unterstützung von Drittanbieteridentitäten einzurichten:

• Mit dem mit EKS verknüpften Cluster verbinden
• Mit dem mit AKS verknüpften Cluster verbinden
• Verbindung zu anderen Clustertypen herstellen

Prüfen, ob GKE Identity Service installiert ist

GKE Identity Service ist standardmäßig ab Version 1.7 auf GKE-Clustern installiert. Die Unterstützung von Drittanbieteridentitäten erfordert jedoch Version 1.13 oder höher. Mit dem folgenden Befehl können Sie prüfen, ob der Dienst korrekt auf Ihrem Cluster installiert ist:

kubectl --kubeconfig CLUSTER_KUBECONFIG get all -n anthos-identity-service

Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig des Clusters.

Unterstützung von externen Identitäten für Gruppen konfigurieren

Wenn Ihr Cluster oder Ihre Flotte bereits für die Unterstützung von Google Groups konfiguriert ist, sind keine weiteren Schritte erforderlich. Sie können mit Drittanbieter-Nutzern und ‑gruppen IAM-Rollen zuweisen fortfahren.

Wenn Sie Google Distributed Cloud auf VMware oder Bare Metal verwenden, hängt die Konfiguration der Drittanbietergruppen-Funktion davon ab, wie Sie GKE Identity Service einrichten.

Wenn Sie GKE Identity Service zum ersten Mal verwenden, können Sie die Unterstützung von Drittanbietergruppen mit Fleet APIs (empfohlen) oder mit kubectl konfigurieren.

Wenn Sie GKE Identity Service bereits verwenden, beachten Sie Folgendes:

• Wenn Sie bereits GKE Identity Service für einen anderen Identitätsanbieter auf Flottenebene eingerichtet haben, ist die Drittanbieter-Gruppenfunktion standardmäßig für Sie aktiviert. Weitere Informationen und ggf. erforderliche zusätzliche Einstellungen finden Sie unten im Abschnitt Flotte.

• Wenn Sie bereits GKE Identity Service für einen anderen Identitätsanbieter für jeden Cluster eingerichtet haben, finden Sie im Abschnitt Kubectl unten eine Anleitung zum Aktualisieren Ihrer Konfiguration für die Drittanbieter-Gruppenfunktion.

Flotte

Sie können den Zugriff auf Drittanbietergruppen über die Google Cloud Konsole oder die Befehlszeile mit Fleet Feature APIs konfigurieren.

Console

Wenn Sie GKE Identity Service noch nicht für eine Flotte eingerichtet haben, folgen Sie der Anleitung unter Cluster für GKE Identity Service konfigurieren.

Cluster auswählen und Konfiguration aktualisieren

1. Rufen Sie in der Google Cloud Console die Seite Feature Manager auf.

   Zu Feature Manager

2. Klicken Sie im Bereich Identity Service auf Details. Die Clusterdetails Ihres Projekts werden angezeigt.

3. Klicken Sie auf Identitätsdienst aktualisieren, um den Einrichtungsbereich zu öffnen.

4. Wählen Sie die Cluster aus, die Sie konfigurieren möchten. Sie können einzelne Cluster auswählen oder festlegen, dass alle Cluster mit derselben Identitätskonfiguration konfiguriert werden sollen.

5. Im Abschnitt Identitätsanbieter konfigurieren können Sie einen Identitätsanbieter beibehalten, hinzufügen, aktualisieren oder entfernen.

6. Klicken Sie auf Weiter, um mit dem nächsten Konfigurationsschritt fortzufahren. Wenn Sie mindestens einen geeigneten Cluster für diese Einrichtung ausgewählt haben, wird der Bereich Google-Authentifizierung angezeigt.

7. Wählen Sie Aktivieren aus, um die Google-Authentifizierung für die ausgewählten Cluster zu aktivieren. Wenn Sie über einen Proxy auf den Google-Identitätsanbieter zugreifen müssen, geben Sie die Proxy-Details ein.

8. Klicken Sie auf Konfiguration aktualisieren. Dadurch wird die Identitätskonfiguration auf die ausgewählten Cluster angewendet.

gcloud

Wenn Sie GKE Identity Service noch nicht für eine Flotte eingerichtet haben, folgen Sie der Anleitung unter Cluster für GKE Identity Service konfigurieren. Geben Sie in der auth-config.yaml-Datei nur die folgende Konfiguration an:

spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false

Zugriff auf Drittanbietergruppen über einen Proxy konfigurieren

Wenn Sie über einen Proxy auf den Identitätsanbieter zugreifen müssen, verwenden Sie in der auth-config.yaml-Datei ein proxy-Feld. Diese Angabe ist möglicherweise erforderlich, wenn sich der Cluster beispielsweise in einem privaten Netzwerk befindet und eine Verbindung zu einem öffentlichen Identitätsanbieter hergestellt werden muss. Sie müssen diese Konfiguration hinzufügen, auch wenn Sie GKE Identity Service bereits für einen anderen Anbieter konfiguriert haben.

Um den proxy zu konfigurieren, müssen Sie den Abschnitt authentication der vorhandenen Konfigurationsdatei auth-config.yaml aktualisieren.

  spec:
    authentication:
    - name: authentication-method
      google:
        disable: false
      proxy: PROXY_URL

Dabei gilt:

• disable (optional): gibt an, ob die Drittanbietergruppen-Funktion für Cluster aktiviert oder deaktiviert werden soll. Dieser Wert ist standardmäßig auf false festgelegt. Wenn Sie diese Funktion deaktivieren möchten, können Sie sie auf true setzen.

• PROXY_URL (optional): Proxyserver-Adresse für die Verbindung mit der Google-ID. Beispiel: http://user:password@10.10.10.10:8888

Wenden Sie die Konfiguration an

Führen Sie den folgenden Befehl aus, um die Konfiguration auf einen Cluster anzuwenden:

gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml

Dabei gilt:

CLUSTER_NAME ist der eindeutige Mitgliedschaftsname Ihres Clusters innerhalb der Flotte.

Nach der Anwendung wird diese Konfiguration vom GKE Identity Service-Controller verwaltet. Alle lokalen Änderungen, die an der Clientkonfiguration von GKE Identity Service vorgenommen werden, werden vom Controller wieder auf die Konfiguration umgestellt, die in dieser Einrichtung festgelegt wurde.

kubectl

Wenn Sie Ihren Cluster so konfigurieren möchten, dass er GKE Identity Service mit der Funktion für Drittanbietergruppen verwendet, müssen Sie die GKE Identity Service-ClientConfig des Clusters aktualisieren. Dies ist ein benutzerdefinierter Kubernetes-Ressourcentyp (CRD), der für die Clusterkonfiguration verwendet wird. Jeder Cluster hat eine ClientConfig-Ressource namens default im Namespace kube-public, die Sie mit Ihren Konfigurationsdetails aktualisieren.

Führen Sie den folgenden Befehl aus, um die Konfiguration zu bearbeiten:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

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.

Im folgenden Beispiel wird gezeigt, wie Sie die ClientConfig mit einer neuen Authentifizierungsmethode mit einer Konfiguration vom Typ google aktualisieren, um die Funktion für Drittanbietergruppen zu aktivieren. Wenn das Feld internalServer leer ist, muss es auf https://kubernetes.default.svc festgelegt werden, wie unten dargestellt.

spec:
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method
    proxy: PROXY_URL
  internalServer: https://kubernetes.default.svc

Dabei gilt:

CLUSTER_IDENTIFIER (erforderlich): gibt die Mitgliedschaftsdetails Ihres Clusters an. Sie können die Mitgliedschaftsdetails Ihres Clusters mit dem folgenden Befehl abrufen:

kubectl --kubeconfig CLUSTER_KUBECONFIG get memberships membership -o yaml

Dabei gilt:

Dabei ist CLUSTER_KUBECONFIG der Pfad der kubeconfig-Datei für den Cluster. In der Antwort finden Sie im Feld spec.owner.id die Mitgliedschaftsdetails des Clusters.

Hier ist ein Beispiel für eine Antwort mit den Mitgliedschaftsdetails eines Clusters:

id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef

Das entspricht dem folgenden Format: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP

Drittanbieternutzern und ‑gruppen IAM-Rollen zuweisen

Drittanbieteridentitäten benötigen die folgenden zusätzlichen Google Cloud Rollen, um über das Gateway mit verbundenen Clustern zu interagieren:

• roles/gkehub.gatewayAdmin: Mit dieser Rolle können Nutzer auf die Connect Gateway API zugreifen.
  • Wenn Nutzer nur Lesezugriff auf verbundene Cluster benötigen, kann stattdessen roles/gkehub.gatewayReader verwendet werden.
  • Wenn Nutzer Lese-/Schreibzugriff auf verbundene Cluster benötigen, kann stattdessen roles/gkehub.gatewayEditor verwendet werden.
• roles/gkehub.viewer: Mit dieser Rolle können Nutzer registrierte Clustermitgliedschaften ansehen.

Im Folgenden wird beschrieben, wie Sie einzelnen Identitäten und zugeordneten Gruppen die erforderlichen Rollen hinzufügen:

Einzelne Identitäten

Führen Sie den folgenden Befehl aus, um einer einzelnen Identität für das Projekt PROJECT_ID die erforderlichen Rollen zuzuweisen:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

Dabei gilt:

• PROJECT_ID ist die ID des Projekts.
• GATEWAY_ROLE ist wahlweise roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader oder gkehub.gatewayEditor.
• WORKFORCE_POOL_ID: die ID des Workforce Identity-Pools.
• SUBJECT_VALUE: die Nutzeridentität.

Gruppen

Führen Sie den folgenden Befehl aus, um allen Identitäten innerhalb einer bestimmten Gruppe für das Projekt PROJECT_ID die erforderlichen Rollen zuzuweisen:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

Dabei gilt:

• PROJECT_ID ist die ID des Projekts.
• GATEWAY_ROLE ist wahlweise roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader oder gkehub.gatewayEditor.
• WORKFORCE_POOL_ID: die ID des Workforce-Pools.
• GROUP_ID: eine Gruppe im zugeordneten google.groups-Anspruch.

Weitere Anpassungen, z. B. die Angabe von Abteilungsattributen, beim Anwenden der RBAC-Richtlinien, finden Sie in der Einrichtung Ihres Identitätsanbieters unter Drittanbieterzuordnungen mit Workforce Identity einrichten.

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

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 über das Gateway von Ihren angegebenen Drittnutzern und -gruppen eingehen. Für jeden Cluster müssen Sie eine RBAC-Berechtigungsrichtlinie hinzufügen, die angibt, welche Berechtigungen die Person für den Cluster hat.

Hinweis :Der Ressourcenpfad für einen Drittanbieternutzer enthält nicht den Namen des Identitätsanbieters. Achten Sie darauf, dass Sie nicht dieselben Nutzer- oder Gruppennamen bei verschiedenen Identitätsanbietern für den gleichen Personalpool verwenden, um unerwartete Berechtigungen zu vermeiden.

Die Subjekte in RBAC-Richtlinien müssen dasselbe Format wie die IAM-Bindungen haben. Drittanbieternutzer beginnen mit principal://iam.googleapis.com/ und Drittanbietergruppen mit principalSet://iam.googleapis.com/. Wenn GKE Identity Service nicht für den Cluster konfiguriert ist, benötigen Sie zusätzlich zu Rollen/Clusterrollen für einen Drittanbieternutzer auch Identitätsübernahmerichtlinien. Folgen Sie in diesem Fall dieser Anleitung zur RBAC-Einrichtung und fügen Sie das Drittanbieter-Hauptkonto, das mit principal://iam.googleapis.com/ beginnt, als Nutzer hinzu.

Das folgende Beispiel zeigt, wie Sie Mitgliedern einer Drittanbietergruppe cluster-admin Berechtigungen für einen Cluster gewähren, in dem der GKE Identity Service konfiguriert ist. Sie können die Richtliniendatei dann als /tmp/admin-permission.yaml speichern und auf den Cluster anwenden, 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-group
subjects:
- kind: Group
  name: "principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

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

Hinweise Während unsere Beispiele zeigen, wie Richtlinienaktualisierungen direkt mit kubectl durchgeführt werden, empfehlen wir für den praktischen Einsatz dringend die Verwendung von Policy Controller zum Erstellen und Verwalten von Richtlinien und Config Sync zum Synchronisieren dieser Richtlinien und anderer Konfigurationen in Ihren Clustern.

Nächste Schritte

• Verbindung über Cluster über die Befehlszeile herstellen
• Ein Beispiel für die Verwendung des Connect-Gateways als Teil Ihrer DevOps-Automatisierung finden Sie in unserer Anleitung In Cloud Build einbinden