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 Übersicht über Connect-Gateway vertraut sein. Informationen zum Autorisieren einzelner Google-Konten finden Sie unter Connect-Gateway einrichten. Informationen zum Google Groups-Support finden Sie unter Connect-Gateway mit Google Groups einrichten.

Mit der Einrichtung in diesem Leitfaden können sich Nutzer über die Google Cloud CLI, das Connect-Gateway und die Google Cloud Console in Flottenclustern anmelden.

Unterstützte Clustertypen

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

• GKE-Cluster
• GKE on VMware und GKE on Bare Metal ab GKE Enterprise 1.13 und höher
• GKE on AWS und GKE on Azure ab Kubernetes Version 1.25
• Angehängte Cluster ab GKE Enterprise 1.16 und höher

Wenn Sie lokale Cluster für die Verwendung dieses Features aktualisieren müssen, Upgrade von GKE Enterprise-Clustern für VMWare und Upgrade von GKE Enterprise-Clustern auf Bare-Metal ausführen.

Wenn Sie einen Anwendungsfall für GKE-Clusterumgebungen als die oben aufgeführten haben, wenden Sie sich 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. Mithilfe der Workforce Identity-Föderation können Nutzer ihre externen Identitätsanbieter wie Okta oder Azure Active Directory verwenden, um über Connect Gateway Zugriff auf ihre Cluster zu erhalten. 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 relevanten externen Identitätsanbieter enthält.

• SUBJECT_VALUE ist die Zuordnung der Identität eines Drittanbieters zu einem Google-Thema.

Bei Drittanbietergruppen hat das IAM-Hauptkonto das folgende Format:

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

Im Folgenden wird der typische Ablauf für einen Drittanbieternutzer gezeigt, der sich bei einem Anthos-Cluster authentifiziert und Befehle für den Dienst ausführt, wobei dieser Dienst aktiviert ist. Damit dieser Ablauf erfolgreich ist, muss eine rollenbasierte Zugriffssteuerungsrichtlinie (Role-based Access Control, RBAC) auf den Cluster für den Nutzer oder eine Gruppe angewendet werden.

Für einzelne Nutzer muss im Cluster eine RBAC-Richtlinie vorhanden sein, die den vollständigen IAM-Hauptkontonamen des Nutzers verwendet.

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

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

2. Ist in einer Zuordnung für einen Identitätsanbieter innerhalb eines Workforce-Pools in der Google Cloud-Organisation von Alice enthalten.

Hinweis: GKE Identity Service muss konfiguriert sein, damit Gruppen-Funktionen von Drittanbietern auf Anthos-Clustern funktionieren.

1. Der Nutzer [e-mail] meldet sich über die browserbasierte Anmeldung eines Drittanbieters mit der Identität des Drittanbieters in gcloud an. Um den Cluster über die Befehlszeile zu verwenden, erhält der Nutzer das Gateway des Clusters kubeconfig, 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 Console öffnet.
3. Die Anfrage wird vom Connect-Gateway empfangen, das die Authentifizierung des Drittanbieters mithilfe von Workforce Identity Federation 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 des Drittanbieters 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 von Google Cloud CLI, dem Befehlszeilentool für die Interaktion mit Google Cloud.
  • Das Kubernetes-Befehlszeilentool kubectl für die Interaktion mit Ihren Clustern.

  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 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 Cloud muss 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 Ihres Identitätsanbieters:

• Azure AD
• Okta
• Anderes OIDC oder SAML 2.0

Hinweis: Für jeden Identitätsanbieter gilt ein Limit von 4 Kilobyte für die Attributzuordnung, einschließlich Gruppen.{/

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

Das Drittanbieter-Identitätssupport-Feature des Connect Gateways verwendet GKE Identity Service, um Informationen zur Mitgliedschaft in Drittanbietergruppen von Google abzurufen. Weitere Informationen zu GKE Identity Service finden Sie unter Einführung in GKE Identity Service.

Installation von GKE Identity Service prüfen

GKE Identity Service ist standardmäßig ab Version 1.7 auf GKE-Clustern installiert. Für den Identitätssupport von Drittanbietern ist jedoch Version 1.13 oder höher erforderlich. 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 Drittanbieteridentitäten für Gruppen konfigurieren

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

Wenn Sie GKE on Bare Metal oder GKE on VMware verwenden, wird durch die Einrichtung von GKE Identity Service bestimmt, wie Sie das Drittanbieter-Gruppenfeature konfigurieren müssen.

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

Wenn Sie GKE Identity Service noch nicht zum ersten Mal verwenden, beachten Sie Folgendes:

• Wenn Sie bereits GKE Identity Service für einen anderen Identitätsanbieter auf Flottenebene eingerichtet haben, ist das Feature für Drittanbieter-Gruppen standardmäßig für Sie aktiviert. Weitere Informationen und gegebenenfalls zusätzliche Einrichtungsschritte finden Sie unten im Abschnitt Flotten.

• Wenn Sie GKE Identity Service bereits für einen anderen Identitätsanbieter eingerichtet haben, lesen Sie unten den Abschnitt Kubectl. Dort finden Sie eine Anleitung zum Aktualisieren Ihrer Konfiguration für den Drittanbieter. Gruppenfunktion.

Flotte

Sie können die Google Cloud Console oder die Befehlszeile verwenden, um den Zugriff auf Drittanbietergruppen mithilfe von Fleet Feature APIs zu 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 GKE Enterprise-Seite Features auf.

   Zu GKE Enterprise-Features

2. Klicken Sie in der Tabelle Produkte in der Zeile 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 zulässigen Cluster für diese Einrichtung ausgewählt haben, wird der Abschnitt 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 Proxydetails 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 Datei auth-config.yaml 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 das Feld proxy in Ihrer auth-config.yaml-Datei. 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 auch dann hinzufügen, wenn Sie GKE Identity Service bereits für einen anderen Anbieter konfiguriert haben.

So konfigurieren Sie proxy, indem Sie den Abschnitt authentication der vorhandenen Konfigurationsdatei auth-config.yaml aktualisieren:

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

Wobei Folgendes gilt:

• disable (optional) gibt an, ob Sie die Drittanbieter-Gruppenfunktion für Cluster aktivieren oder deaktivieren möchten. Dieser Wert ist standardmäßig auf false gesetzt. Wenn Sie diese Funktion deaktivieren möchten, setzen Sie sie auf true.

• PROXY_URL (optional) ist die Adresse des Proxyservers, mit der eine Verbindung zur Google-Identität hergestellt werden soll. Beispiel: http://user:password@10.10.10.10:8888

Wenden Sie die Konfiguration an

Führen Sie 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

Wobei Folgendes 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 diesem Setup festgelegt wurde.

kubectl

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

Verwenden Sie den folgenden Befehl, 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 finden Sie ein Beispiel dafür, wie Sie ClientConfig mit einer neuen Authentifizierungsmethode mit der Konfiguration vom Typ google aktualisieren können, um das Feature für Drittanbieter-Gruppen zu aktivieren. Wenn das Feld internalServer leer ist, achten Sie darauf, dass es auf https://kubernetes.default.svc gesetzt ist, wie unten gezeigt.

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

Wobei Folgendes gilt:

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

kubectl --kubeconfig CLUSTER_KUBECONFIG get memberships membership -o yaml

Wobei Folgendes gilt:

Dabei ist CLUSTER_KUBECONFIG der Pfad der kubeconfig-Datei für den Cluster. Lesen Sie in der Antwort das Feld spec.owner.id, um die Mitgliedschaftsdetails des Clusters abzurufen.

Hier sehen Sie eine Beispielantwort mit den Mitgliedschaftsdetails eines Clusters:

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

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

IAM-Rollen für Drittanbieter-Nutzer und -Gruppen zuweisen

Drittanbieter-Identitä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 verbundenen Clustern benötigen, kann stattdessen roles/gkehub.gatewayEditor verwendet werden.
• roles/gkehub.viewer Mit dieser Rolle können Nutzer registrierte Clustermitgliedschaften aufrufen.

Im Folgenden wird gezeigt, 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"

Wobei Folgendes gilt:

• PROJECT_ID ist die ID des Projekts.
• GATEWAY_ROLE ist wahlweise roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader oder gkehub.gatewayEditor.
• WORKFORCE_POOL_ID ist die ID des Mitarbeiteridentitätspools.
• SUBJECT_VALUE ist 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"

Wobei Folgendes gilt:

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

Weitere Anpassungen, z. B. zum Angeben von Abteilungsattributen, wenn Sie die RBAC-Richtlinie anwenden, finden Sie in der Einrichtung für Ihren Identitätsanbieter, die unter Drittanbieterzuordnungen mit Workforce Identity einrichten aufgeführt ist.

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 das Gateway von Ihren angegebenen Drittanbieternutzern und -gruppen aus erlaubt. 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. Um unerwartete Berechtigungen zu vermeiden, sollten Sie darauf achten, dass Sie nicht dieselben Nutzer- oder Gruppennamen bei verschiedenen Identitätsanbietern für einen einzelnen Mitarbeiterpool verwenden.

Die Betreffe in RBAC-Richtlinien müssen dasselbe Format wie die IAM-Bindungen haben, wobei Drittanbieternutzer mit principal://iam.googleapis.com/ und Drittanbietergruppen mit principalSet://iam.googleapis.com/ beginnen. Wenn GKE Identity Service nicht für den Cluster konfiguriert ist, benötigen Sie zusätzlich zu den Rollen/Clusterrollen für einen Drittanbieternutzer Richtlinien zum Identitätswechsel. Führen Sie in diesem Fall diese RBAC-Einrichtungsschritte aus und fügen Sie das Drittanbieterhauptkonto, das mit principal://iam.googleapis.com/ beginnt, als Nutzer hinzu.

Das folgende Beispiel zeigt, wie Sie Mitgliedern einer Drittanbietergruppe cluster-admin-Berechtigungen in einem Cluster gewähren, in dem GKE Identity Service konfiguriert ist. Sie können die Richtliniendatei dann unter /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