Externe Identitätsanbieter zur Authentifizierung bei GKE verwenden

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite erfahren Sie, wie Sie die Authentifizierung bei GKE-Clustern (Google Kubernetes Engine) über externe Identitätsanbieter (IdPs) konfigurieren.

Diese Seite richtet sich an Plattformadministratoren und ‑bearbeiter sowie Identitäts- und Kontoadministratoren, die einen externen Identitätsanbieter verwenden, der OpenID Connect (OIDC) oder Security Assertion Markup Language (SAML) 2.0 unterstützt.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Authentifizierungs- und OpenID-Konzepten vertraut:

• OAuth 2.0
• SAML 2.0
• OpenID Connect
• OIDC-Bereiche und -Anspruche
• Kubernetes RBAC

Authentifizierungsmethoden für externe Identitätsanbieter in GKE

Empfohlen: Mitarbeiteridentitätsföderation

Die Workforce Identity-Föderation ist eine IAM-Funktion, mit der Sie sich über einen beliebigen externen Identitätsanbieter, der OIDC oder SAML 2.0 unterstützt, bei Google Cloud authentifizieren können. Für die Mitarbeiteridentitätsföderation ist keine Installation im Cluster erforderlich. Sie funktioniert mit Autopilot- und Standardclustern und ist in Google Cloudintegriert. Weitere Informationen finden Sie in der IAM-Dokumentation zur Workforce Identity-Föderation.

Nicht empfohlen: Identity Service for GKE

Nur in GKE Standard-Clustern unterstützt GKE auch Identity Service for GKE. Identity Service for GKE ist auf OIDC-Identitätsanbieter beschränkt und es werden zusätzliche Komponenten in Ihrem Cluster installiert. Für GKE wird dringend empfohlen, die Workforce Identity-Föderation anstelle von Identity Service for GKE zu verwenden.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Hinweise

Monitorlose Systeme werden sowohl von der Workforce Identity-Föderation als auch vom Identity Service for GKE nicht unterstützt. Bei einem browserbasierten Authentifizierungsvorgang werden Sie zur Zustimmung aufgefordert, um dann Ihr Nutzerkonto zu autorisieren.

Workforce Identity Federation in GKE verwenden

So verwenden Sie die Workforce Identity Federation in Ihren GKE-Clustern:

1. Richten Sie die Mitarbeiteridentitätsföderation für Ihre Organisation und den externen IdP ein. Eine Anleitung finden Sie unter Workforce Identity-Föderation konfigurieren.
2. Richten Sie den Zugriff Ihres externen IdP auf die Google Cloud Workforce Identity-Föderationskonsole ein. Weitere Informationen finden Sie unter Nutzerzugriff auf die Console (föderiert) einrichten.

3. Konfigurieren Sie den Nutzerzugriff mithilfe eines der folgenden Autorisierungsmechanismen:

   • Kubernetes RBAC
   • IAM-Zulassungsrichtlinien

4. Bitten Sie Ihre Nutzer, die folgenden Schritte auszuführen, um auf Cluster zuzugreifen:

   1. Melden Sie sich mit der föderierten Identität in der gcloud CLI an.
   2. Konfigurieren Sie kubectl so, dass es sich bei einem bestimmten Cluster authentifiziert. Führen Sie dazu gcloud container clusters get-credentials aus.

Nutzerzugriff auf Cluster mit RBAC konfigurieren

Google Cloud verwendet Hauptkonto-IDs, um Nutzer in Ihren Workforce Identity-Pools zu identifizieren. Sie können in Ihren Kubernetes-RBAC-Richtlinien oder IAM-Richtlinien auf diese Hauptkonto-IDs verweisen. Sie können Berechtigungen für einzelne Nutzer oder Nutzergruppen gewähren, wie in den folgenden Beispielen:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE

principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com

principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME

principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

Informationen zu jeder Hauptkonto-ID, die von der Workforce Identity-Föderation unterstützt wird, finden Sie unter Workforce-Pool-Nutzer in IAM-Richtlinien darstellen.

Im folgenden Beispiel wird gezeigt, wie Sie allen Entitäten im Workforce-Pool full-time-employees, die das Attribut access_level="sensitive" in ihrem IdP-Token haben, clusterweit Lesezugriff auf Secrets gewähren.

1. Speichern Sie das folgende ClusterRole-Manifest als secret-viewer-cluster-role.yaml:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-viewer
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   

   Alle Hauptkonten, denen Sie diese ClusterRole binden, können Secrets aufrufen.

2. Speichern Sie das folgende ClusterRoleBinding-Manifest als secret-viewer-cluster-role-binding.yaml:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  users-view-secrets
   subjects:
   - kind: Group
     name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/attribute.access_level/sensitive
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

   Mit dieser ClusterRoleBinding wird allen Nutzern mit dem Attribut access_level="sensitive" die ClusterRole secret-viewer gewährt.

3. Stellen Sie die ClusterRole und die ClusterRoleBinding bereit:

   kubectl apply -f secret-viewer-cluster-role.yaml
   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

Beim Cluster anmelden und authentifizieren

1. Bitte den Nutzer, sich über die Google Cloud CLI für Google Cloudanzumelden.

2. Der Nutzer kann kubectl so konfigurieren, dass es sich beim Cluster authentifiziert. Dazu stehen folgende Optionen zur Verfügung:

   gcloud container clusters get-credentials
   

Identity Service for GKE-Cluster zur Workforce Identity Federation migrieren

Wenn Sie Identity Service for GKE in vorhandenen GKE-Clustern verwenden, migrieren Sie zu Workforce Identity Federation. Bei diesen Methoden wird auf dieselben Hauptrollen verwiesen, jedoch mit unterschiedlicher Syntax, wie in der folgenden Tabelle dargestellt:

So migrieren Sie einen Cluster zur Verwendung der Workforce Identity-Föderation:

1. Richten Sie die Mitarbeiteridentitätsföderation für Ihre Organisation und den externen IdP ein. Eine Anleitung finden Sie unter Workforce Identity-Föderation konfigurieren.

2. Aktualisieren Sie die Manifeste für alle RoleBindings und ClusterRoleBindings in Ihren Clustern, um die Syntax der Workforce Identity-Föderation zu verwenden. Verwenden Sie eine der folgenden Optionen:

   • Programmatische Updates: Installieren und führen Sie das Dienstprogramm gke-identity-service-migrator aus. Eine Anleitung finden Sie in der GoogleCloudPlatform/gke-utilities-Repository-README.

     Dieses Dienstprogramm sucht nach vorhandenen RBAC-Bindungen, die die Syntax von Identity Service for GKE verwenden, und erstellt neue Manifeste, die die entsprechenden Identitäts-IDs der Workforce Identity Federation verwenden.

   • Manuelle Aktualisierungen: Erstellen Sie für jede Bindung, die auf einen authentifizierten Nutzer oder eine Gruppe verweist, eine separate Kopie der Manifestdatei des Objekts, die die Syntax der Workforce Identity Federation-Kennung verwendet.

3. Wenden Sie die aktualisierten Manifeste für RoleBindings und ClusterRoleBindings auf Ihren Cluster an.

4. Testen Sie, ob Nutzer auf dieselben Ressourcen zugreifen können, wenn sie sich mit der Workforce Identity Federation authentifizieren.

5. Entfernen Sie die veralteten RBAC-Bindungen aus Ihrem Cluster.

6. Deaktivieren Sie Identity Service for GKE.

Identity Service for GKE verwenden

Zum Einrichten und Verwenden von Identity Service for GKE in Ihrem GKE-Cluster im Standardmodus tun Clusteradministratoren Folgendes:

1. Identity Service for GKE in einem Cluster konfigurieren.
2. Identity Service for GKE konfigurieren.
3. RBAC-Richtlinie für Ihren Cluster erstellen.

Nachdem Clusteradministratoren Identity Service for GKE konfiguriert haben, können sich Entwickler im Cluster anmelden und sich authentifizieren.

Von Identity Service for GKE erstellte Kubernetes-Objekte

In folgender Tabelle werden die Kubernetes-Objekte beschrieben, die beim Aktivieren von Identity Service for GKE für einen Cluster erstellt werden:

Identity Service for GKE in einem Cluster aktivieren

Standardmäßig ist Identity and Access Management (IAM) als Identitätsanbieter für die Clusterauthentifizierung konfiguriert. Wenn Sie OIDC mit externen Identitätsanbietern verwenden möchten, können Sie Identity Service for GKE über die Google Cloud-Befehlszeile auf neuen oder vorhandenen Clustern aktivieren.

Identity Service for GKE für einen neuen Cluster aktivieren

Führen Sie folgenden Befehl aus, um einen Cluster mit aktiviertem Identity Service for GKE zu erstellen:

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

Ersetzen Sie dabei CLUSTER_NAME durch den Namen des neuen Clusters.

Identity Service for GKE auf einem vorhandenen Cluster aktivieren

Führen Sie folgenden Befehl aus, um Identity Service for GKE auf einem vorhandenen Cluster zu aktivieren:

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

Identity Service for GKE konfigurieren

Um Identity Service for GKE-Parameter zu konfigurieren, laden Sie die ClientConfig default herunter und bearbeiten sie.

1. Laden Sie die default-ClientConfig herunter:

   kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml
   

2. Aktualisieren Sie den spec.authentication-Abschnitt mit Ihren bevorzugten Einstellungen:

   apiVersion: authentication.gke.io/v2alpha1
   kind: ClientConfig
   metadata:
     name: default
     namespace: kube-public
   spec:
     name: cluster-name
     server: https://192.168.0.1:6443
     authentication:
     - name: oidc
       oidc:
         clientID: CLIENT_ID
         certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
         extraParams: EXTRA_PARAMS
         issuerURI:  ISSUER_URI
         cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
         kubectlRedirectURI: KUBECTL_REDIRECT_URL
         scopes: SCOPES
         userClaim: USER
         groupsClaim: GROUPS
         userPrefix: USER_PREFIX
         groupPrefix: GROUP_PREFIX
   

   Ersetzen Sie Folgendes:

   • CLIENT_ID durch die ID der Clientanwendung, die Authentifizierungsanfragen an den OIDC-Anbieter sendet.
   • OIDC_PROVIDER_CERTIFICATE: (Optional) Ein PEM-Zertifikat für den OIDC-Anbieter. Dieses Feld kann hilfreich sein, wenn Ihr OIDC-Anbieter selbstsignierte Zertifikate verwendet. Identity Service for GKE enthält standardmäßig eine Reihe öffentlicher Roots.
   • EXTRA_PARAMS: Zusätzliche Schlüssel/Wert-Parameter, die an den OIDC-Anbieter gesendet werden.
     • Verwenden Sie resource=token-groups-claim zum Autorisieren von Gruppen.
     • Verwenden Sie prompt=consent zur Authentifizierung von Microsoft Azure und Okta.
     • Verwenden Sie prompt=consent,access_type=offline für Cloud Identity.
   • ISSUER_URI: Die URL, an die OIDC-Autorisierungsanfragen gesendet werden, z. B. https://example.com/adfs. Der Kubernetes API-Server nutzt diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens zu ermitteln. Für den URI muss HTTPS verwendet werden. Verwenden Sie https://accounts.google.com für Cloud Identity.
   • KUBECTL_REDIRECT_URL: Die Weiterleitungs-URL, die kubectl oidc login für die Autorisierung verwendet. Sie hat in der Regel das Format http://localhost:PORT/callback, wobei PORT ein beliebiger Port über 1024 ist, der auf Entwickler-Workstations verfügbar ist, wie z. B. http://localhost:10000/callback. Sie müssen die URL bei Ihrem OIDC-Anbieter als autorisierte Weiterleitungs-URL für die Clientanwendung registrieren. Wenn Sie Google Identity als OIDC-Anbieter verwenden, folgen Sie der Anleitung unter Weiterleitungs-URI festlegen.
   • SCOPES: Zusätzliche Bereiche, die an den OIDC-Anbieter gesendet werden.
     • Microsoft Azure und Okta benötigen den Bereich offline_access.
     • Verwenden Sie für Cloud Identity openid, email, um ID-Tokens abzurufen, die die E-Mail-Adresse im Anforderung email enthalten.
   • USER: Die Nutzeranforderung aus dem Identitätstoken.
   • GROUPS: Die Gruppenanforderung aus dem Identitätstoken.
   • USER_PREFIX: Das Präfix, das Gruppenanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Standardmäßig wird ein Ausstellerpräfix an userID angehängt, der dem Kubernetes API-Server zugewiesen ist (es sei denn, der Nutzeranspruch ist email). Die resultierende Nutzer-ID lautet ISSUER_URI#USER. Wir empfehlen die Verwendung eines Präfixes. Wenn Sie das Präfix deaktivieren wollen, setzen Sie USER_PREFIX auf -.
   • GROUP_PREFIX: Das Präfix, das Gruppenanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Wenn Sie beispielsweise zwei Gruppen mit dem Namen foobar haben, fügen Sie das Präfix gid- hinzu. Die resultierende Gruppe ist gid-foobar.

3. Wenden Sie die aktualisierte Konfiguration an:

   kubectl apply -f client-config.yaml
   

   Nachdem Sie diese Konfiguration angewendet haben, wird Identity Service for GKE in Ihrem Cluster ausgeführt und verarbeitet Anfragen hinter dem Load-Balancer gke-oidc-envoy. Die IP-Adresse im Feld spec.server muss die IP-Adresse des Load Balancers sein. Wenn Sie das Feld spec.server ändern, können kubectl-Befehle fehlschlagen.

4. Erstellen Sie eine Kopie der Konfigurationsdatei client-config.yaml:

   cp client-config.yaml login-config.yaml
   

5. Aktualisieren Sie die Konfigurationsdatei login-config.yaml mit der Einstellung clientSecret im Abschnitt spec.authentication.oidc.

   clientSecret: CLIENT_SECRET
   

   Ersetzen Sie CLIENT_SECRET durch das gemeinsame Secret zwischen der OIDC-Clientanwendung und dem OIDC-Anbieter.

6. Verteilen Sie die aktualisierte Datei login-config.yaml an Ihre Entwickler.

Identity Service for GKE auf Clustern mit strengen Richtlinien konfigurieren

So konfigurieren Sie Identity Service for GKE für Cluster, die strenge Netzwerkrichtlinien haben:

1. Fügen Sie eine Firewallregel für den TCP-Port 15000 hinzu, damit die Steuerungsebene mit dem ClientConfig-Validierungs-Webhook kommunizieren kann.
2. Wenn die gke-oidc-envoy als interner Load-Balancer erstellt wird, stellen Sie sie in Ihrer VPC bereit.
3. Wenn Richtlinien in Ihrem Cluster abgelehnt werden, fügen Sie eine Firewallregel für den TCP-Port 8443 hinzu, damit die Bereitstellung gke-oidc-envoy mit der Bereitstellung gke-oidc-service kommunizieren kann.

Die Komponente "Identity Service for GKE" Version 0.2.20 und höher verwendet den TCP-Port 15000 nicht. Wenn Ihre Version der Komponente 0.2.20 oder höher ist, müssen Sie keine Firewallregel für Port 15000 hinzufügen. Führen Sie folgenden Befehl aus, um die Version der Komponente zu prüfen:

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

Benutzerdefinierte Attribute zum Load-Balancer hinzufügen

Nachdem Sie Identity Service for GKE konfiguriert haben, können Sie dem gke-oidc-envoy-Load-Balancer benutzerdefinierte Annotationen und Attribute, z. B. eine statische IP-Adresse, hinzufügen. Führen Sie zum Bearbeiten des gke-oidc-envoy-Dienstes den folgenden Befehl aus:

kubectl edit service gke-oidc-envoy -n anthos-identity-service

Weitere Informationen zum Konfigurieren des TCP/UDP-Load Balancing für GKE finden Sie unter LoadBalancer-Dienstparameter.

RBAC-Richtlinie für Ihren Cluster erstellen

Administratoren können mit der rollenbasierten Zugriffssteuerung (Role-based Access Control, RBAC) von Kubernetes authentifizierten Clusternutzern Zugriff gewähren. Zur Konfiguration von RBAC für Ihren Cluster müssen Sie jedem Entwickler RBAC-Rollen zuweisen. Wenn Sie Zugriff auf Ressourcen in einem bestimmten Namespace gewähren möchten, erstellen Sie eine Role und eine RoleBinding. Wenn Sie Zugriff auf Ressourcen auf einem gesamten Cluster gewähren möchten, erstellen Sie eine ClusterRole und eine ClusterRoleBinding.

Angenommen, ein Nutzer muss alle Secret-Objekte im gesamten Cluster anzeigen. Durch die folgenden Schritte werden diesem Nutzer die erforderlichen RBAC-Rollen zugewiesen.

1. Speichern Sie das folgende ClusterRole-Manifest als secret-viewer-cluster-role.yaml. Eine Person, der diese Rolle zugewiesen wurde, kann beliebige Secrets im Cluster abrufen, beobachten und auflisten.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-viewer
   rules:
   - apiGroups: [""]
     # The resource type for which access is granted
     resources: ["secrets"]
     # The permissions granted by the ClusterRole
     verbs: ["get", "watch", "list"]
   

2. Wenden Sie das ClusterRole-Manifest an:

   kubectl apply -f secret-viewer-cluster-role.yaml
   

3. Speichern Sie das folgende ClusterRoleBinding-Manifest als secret-viewer-cluster-role-binding.yaml. Durch die Bindung wird einem in der Clientkonfigurationsdatei definierten Nutzernamen die Rolle secret-viewer zugewiesen.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  people-who-view-secrets
   subjects:
   - kind: User
     name: ISSUER_URI#USER
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

   Ersetzen Sie Folgendes:

   • ISSUER_URI durch die Aussteller-URI aus spec.authentication.oidc.issuerURI in der Client-Konfigurationsdatei.
   • USERdurch die Nutzerkennung im Token unter dem Anforderungsnamen, der in spec.authentication.oidc.userClaim in der Client-Konfigurationsdatei konfiguriert ist.

4. Wenden Sie das ClusterRoleBinding-Manifest an:

   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

Beim Cluster anmelden und authentifizieren

Als Entwickler, der die OIDC-Konfigurationsdatei von seinem Administrator erhält, können Sie sich bei Ihren Clustern authentifizieren.

1. Laden Sie die vom Administrator bereitgestellte Datei login-config.yaml herunter.

2. Installieren Sie das Google Cloud CLI-SDK, das eine separate OIDC-Komponente bietet. Zur Installation führen Sie folgenden Befehl aus:

   gcloud components install kubectl-oidc
   

3. Authentifizieren Sie sich bei Ihrem Cluster:

   kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml
   

   Ein Webbrowser wird geöffnet, um den Authentifizierungsvorgang abzuschließen.

4. Nach der Authentifizierung können Sie kubectl-Befehle ausführen, zum Beispiel:

   kubectl get pods
   

Identity Service for GKE deaktivieren

Sie können Identity Service for GKE mit der gcloud CLI deaktivieren. Führen Sie zum Deaktivieren von Identity Service for GKE folgenden Befehl aus:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

Nächste Schritte

• Weitere Informationen zur Workforce Identity-Föderation
• Weitere Informationen zum Bereitstellen von Arbeitslasten