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-Gateways vertraut sein. Informationen zum Autorisieren einzelner Google-Konten finden Sie unter Connect-Gateway einrichten. Informationen zur Google Groups-Unterstützung 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 Clustertypen einrichten:

Wenn Sie dieses Feature in Umgebungen verwenden möchten, die nicht in der vorherigen Liste aufgeführt sind, 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. 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 der IAM-Prinzipal 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 alice@example.com als Mitglied enthält.

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

Diagramm zum Ablauf der Drittanbieteridentität im Gateway

  1. Der Nutzer alice@example.com meldet sich mit seiner Drittanbieteridentität in der gcloud CLI an und verwendet dabei 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 Mitarbeiteridentitätsfö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 die Identitätsdienstkomponente im Cluster weiter, die die Anfrage validiert.
  8. Die Identitätsdienstkomponente 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

  1. Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

  2. Installieren Sie die Google Cloud CLI.

  3. Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

  4. Führen Sie den folgenden Befehl aus, um die gcloud CLI zu initialisieren: 

    gcloud init

  5. Prüfen Sie, ob Sie die Berechtigungen haben, die für diese Anleitung erforderlich sind.

  6. Aktivieren Sie die Connect Gateway-, GKE Connect-, GKE Hub-, Anthos Identity Service- und Cloud Resource Manager-APIs:

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen 

    gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

  7. Installieren Sie die Google Cloud CLI.

  8. Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

  9. Führen Sie den folgenden Befehl aus, um die gcloud CLI zu initialisieren: 

    gcloud init

  10. Prüfen Sie, ob Sie die Berechtigungen haben, die für diese Anleitung erforderlich sind.

  11. Aktivieren Sie die Connect Gateway-, GKE Connect-, GKE Hub-, Anthos Identity Service- und Cloud Resource Manager-APIs:

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen 

    gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com
    12.
  12. Bei Clustern außerhalb von Google Cloudmüssen die Authentifizierungskomponenten in Ihrem Cluster die Cloud Identity API aufrufen. Prüfen Sie, ob Sie Netzwerkrichtlinien haben, die erfordern, dass ausgehender Traffic von Ihrem Cluster über einen Proxy geleitet wird.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Editor (roles/editor) für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Konfigurieren des Connect-Gateways und Ihrer Cluster benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Drittanbieter-Identitätsattributzuordnungen mit Mitarbeiteridentitätsföderation 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:

Support für Gruppen konfigurieren

Das Connect Gateway verwendet Authentifizierungskomponenten in Ihrem Cluster, um Informationen zur Gruppenmitgliedschaft abzurufen. Informationen zum Aktivieren der erforderlichen Komponenten finden Sie in einem der folgenden Dokumente, je nach Clustertyp:

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.

In den folgenden Abschnitten erfahren Sie, wie Sie die benutzerdefinierte ClientConfig-Ressource aktualisieren, um die Gruppenunterstützung zu aktivieren. Diese Abschnitte gelten nur für Google Distributed Cloud-Cluster. Bei anderen Clustertypen wie GKE aufGoogle Cloud, GKE on AWS und GKE on Azure fahren Sie mit dem Abschnitt Gruppen IAM-Rollen zuweisen fort.

In Distributed Cloud können Sie die Unterstützung für Gruppen für einzelne Cluster oder für eine Flotte konfigurieren. Der verwendete Clustertyp bestimmt, wie Sie den Gruppensupport konfigurieren:

  • Distributed Cloud Connected: nur einzelne Cluster. Die Konfiguration auf Flottenebene wird nicht unterstützt.
  • Google Distributed Cloud (nur Software) auf VMware und Bare Metal: einzelne Cluster oder Flotten.

Gruppenunterstützung mit der GKE Fleet API konfigurieren

Für Google Distributed Cloud (nur Software) auf VMware und Bare Metal können Sie die Gruppenunterstützung auf Flottenebene konfigurieren. Wenn Sie die Authentifizierung auf Flottenebene bereits konfiguriert haben, z. B. für einen anderen Identitätsanbieter, ist die Gruppenauthentifizierung bereits aktiviert. Wenn in Ihrer Netzwerkrichtlinie jedoch festgelegt ist, dass ausgehender Traffic einen Proxy durchlaufen muss, müssen Sie die vorhandene Konfiguration mit Informationen zu diesem Proxy aktualisieren.

Wenn Sie die Gruppenunterstützung auf Flottenebene konfigurieren möchten, wählen Sie eine der folgenden Optionen aus:

Console

  1. Rufen Sie in der Google Cloud Console die Seite GKE Identity Service auf.

    Zum GKE Identity Service

  2. Klicken Sie auf Identity Service aktivieren.

  3. Wählen Sie die Google Distributed Cloud (nur Software) on VMware- und Bare Metal-Cluster aus, die Sie konfigurieren möchten.

  4. Klicken Sie auf Konfiguration aktualisieren. Der Bereich Clusterkonfiguration für Identitätsdienst bearbeiten wird geöffnet.

  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

  1. Aktivieren Sie die Funktion für den Identitätsdienst auf Flottenebene und konfigurieren Sie die Cluster wie unter Authentifizierungsverwaltung auf Flottenebene einrichten beschrieben.

  2. Fügen Sie der Datei auth-config.yaml, die Ihre ClientConfig-Spezifikation enthält, das folgende Feld hinzu:

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

    Der Wert von false im Feld google.disable ermöglicht die Unterstützung von Gruppen. Wenn Sie die Unterstützung für Gruppen deaktivieren möchten, ändern Sie diesen Wert in true.

  3. Optional: Wenn Sie über einen Proxy auf den Google-Identitätsanbieter zugreifen müssen, fügen Sie der vorherigen Konfiguration das Feld proxy hinzu:

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

    Ersetzen Sie PROXY_URL durch die Adresse des Proxyservers, mit dem die Verbindung zur Google-Identität hergestellt werden soll. Beispiel: http://user:password@10.10.10.10:8888

  4. Konfiguration auf einen Cluster in Ihrer Flotte anwenden:

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

    Ersetzen Sie CLUSTER_NAME durch den eindeutigen Mitgliedschaftsnamen Ihres Clusters innerhalb der Flotte.

Nachdem Sie die Gruppenunterstützung auf Flottenebene eingerichtet haben, wird die Konfiguration vom Flottencontroller verwaltet. Die Konfiguration auf Flottenebene überschreibt alle lokalen Änderungen, die Sie an der Konfiguration in einem bestimmten Cluster vornehmen.

Gruppenunterstützung für einzelne Cluster konfigurieren

Aktivieren Sie für alle Distributed Cloud-Cluster, einschließlich Distributed Cloud Connected, die Gruppenunterstützung, indem Sie die default-ClientConfig in jedem Cluster aktualisieren:

  1. Rufen Sie die Mitgliedschaftsdetails Ihres Clusters ab:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml

    Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der 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.

    In der Antwort finden Sie im Feld spec.owner.id die Mitgliedschaftsdetails des Clusters. Die Mitgliedschafts-ID hat das Format //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP.

    Die Ausgabe sieht etwa so aus:

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

  2. Öffnen Sie die default ClientConfig in Ihrem Cluster zum Bearbeiten:

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

  3. Wenn Sie die Gruppenunterstützung aktivieren möchten, fügen Sie das Feld google dem Feld spec.authentication hinzu:

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

    Ersetzen Sie CLUSTER_IDENTIFIER durch die Mitgliedschaftsdetails Ihres Clusters.

    Das Feld internalServer muss den Wert https://kubernetes.default.svc haben.

  4. Optional: Wenn Sie über einen Proxy auf den Google-Identitätsanbieter zugreifen müssen, fügen Sie der vorherigen Konfiguration das Feld proxy hinzu:

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

    Ersetzen Sie PROXY_URL durch die Adresse des Proxyservers, mit dem die Verbindung zur Google-Identität hergestellt werden soll. Beispiel: http://user:password@10.10.10.10:8888

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 Drittanbieternutzern 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.

Die Subjekte in RBAC-Richtlinien müssen dasselbe Format wie die IAM-Bindungen verwenden. Drittanbieternutzer beginnen mit principal://iam.googleapis.com/ und Drittanbietergruppen mit principalSet://iam.googleapis.com/. Wenn für den Cluster keine Authentifizierung über externe Drittanbieteridentitäten 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.

Im folgenden Beispiel wird gezeigt, wie Mitgliedern einer Drittanbietergruppe cluster-admin Berechtigungen für einen Cluster erteilt werden, in dem die Authentifizierung über externe Drittanbieteridentitäten 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.

Nächste Schritte