Externe Identitätsanbieter zur Authentifizierung bei GKE verwenden

Standard

---

In diesem Dokument wird erläutert, wie Sie einen externen Identitätsanbieter für die Authentifizierung bei GKE-Clustern (Google Kubernetes Engine) konfigurieren.

Übersicht

Identity Service for GKE erweitert Ihre vorhandenen Identitätslösungen für die Authentifizierung in Ihren GKE-Clustern. Mit der Unterstützung von OpenID Connect (OIDC) können Sie den Zugriff auf Kubernetes-Cluster verwalten, indem Sie die Standardverfahren in Ihrer Organisation zum Erstellen, Aktivieren und Deaktivieren von Nutzerkonten verwenden. Identity Service for GKE ist auf OIDC-Identitätsanbieter beschränkt.

Achtung: Überlegen Sie vor der Verwendung von Identity Service for GKE, ob aihcMitarbeiteridentitätsföderation oderWorkload Identity-Föderation für Ihren Anwendungsfall geeignet sind. Mit der Mitarbeiteridentitätsföderation und der Identitätsföderation von Arbeitslasten müssen Sie nicht jeden GKE-Cluster separat konfigurieren. Für die Mitarbeiteridentitätsföderation und die Identitätsföderation von Arbeitslasten sind keine Add-on-Komponenten in jedem Cluster erforderlich.

Hinweise

• Machen Sie sich vor dem Lesen dieses Dokuments mit den folgenden Authentifizierungs- und OpenID-Konzepten vertraut:

  • OAuth 2.0
  • OpenID Connect
  • Bereiche
  • Anforderungen

• Monitorlose Systeme werden nicht unterstützt. Über einen browserbasierten Authentifizierungsvorgang werden Sie zur Zustimmung aufgefordert, um dann Ihr Nutzerkonto zu autorisieren.

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.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Wer verwendet Identity Service for GKE?

Die Aufgaben in diesem Dokument sind relevant, wenn Sie zu einer der folgenden Gruppen gehören:

• Clusteradministrator: Erstellt einen oder mehrere Nutzercluster und Konfigurationsdateien für die Authentifizierung für Entwickler, die die Cluster verwenden.

• Entwickler: Führt Arbeitslasten auf einem oder mehreren Clustern aus und verwendet OIDC zur Authentifizierung.

So gehts:

Zum Einrichten und Verwenden von Identity Service for GKE in Ihrem GKE-Cluster 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.

Identity Service for GKE in einem Cluster aktivieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

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.

Hinweis: Damit Identity Service for GKE ordnungsgemäß funktioniert, stellt GKE Pods auf Ihren Knoten bereit, die erhöhte RBAC-Berechtigungen haben, wie die Fähigkeit, die Identität von Nutzern und Gruppen zu übernehmen. Diese Berechtigungen sind für Identity Service for GKE erforderlich, um die Validierung und Kommunikation von Identitäten basierend auf Ihrer Konfiguration zu erleichtern.

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.

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:

Kubernetes-Objekte
anthos-identity-service	Namespace Wird für den Identity Service for GKE-Bereitstellungen verwendet.
kube-public	Namespace Wird für die default-konfigurationsdatei des Clients verwendet.
gke-oidc-envoy	LoadBalancer Der Endpunkt für OIDC-Anfragen. Standardmäßig extern. Wenn der Endpunkt in einem privaten Cluster oder einem Cluster mit einer strengen Netzwerkrichtlinie erstellt wird, liegt er intern in der Virtual Private Cloud des Clusters. Wird im Namespace anthos-identity-service erstellt.
gke-oidc-service	ClusterIP Ermöglicht die Kommunikation zwischen dem gke-oidc-envoy-Bereitstellung und der gke-oidc-service-Bereitstellung. Wird im Namespace anthos-identity-service erstellt.
gke-oidc-envoy	Deployment Führt einen Proxy aus, der für den Load-Balancer gke-oidc-envoy freigegeben ist. Kommuniziert mit gke-oidc-service, um Identitätstokens zu validieren. Fungiert als Proxy für den Kubernetes API-Server und übernimmt die Identität von Nutzern, wenn Anfragen an den API-Server übergeben werden. Wird im Namespace anthos-identity-service erstellt.
gke-oidc-service	Deployment Validiert Identitätstokens und bietet einen validierenden Zulassungs-Webhook für ClientConfig-Ressourcen. Wird im Namespace anthos-identity-service erstellt.
gke-oidc-operator	Deployment Vergleicht die Clientkonfiguration und den Load-Balancer gke-oidc-envoy. Wird im Namespace anthos-identity-service erstellt.
gke-oidc-certs	Secret Enthält die Cluster-Zertifizierungsstelle (CA) und TLS-Zertifikate für den LoadBalancer. Wird im Namespace anthos-identity-service erstellt.
default	ClientConfig CRD Enthält OIDC-Parameter wie bevorzugte Authentifizierungsmethode, Identitätsanbieterkonfiguration sowie Nutzer- und Gruppenanforderungenzuordnungen. Wird zur Validierung von Identitätstokens verwendet. Wird von Clusteradministratoren verwendet, um OIDC-Einstellungen zu konfigurieren, bevor sie an Entwickler verteilt werden. Wird im Namespace kube-public erstellt.

Identity Service for GKE konfigurieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

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, schlagen kubectl-Befehle möglicherweise fehl.

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, z. B. private Cluster:

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

Lesen Sie in der Dokumentation wie Konfigurieren von TCP/UDP-Load-Balancing für GKE funktioniert.

RBAC-Richtlinie für Ihren Cluster erstellen

Dieser Abschnitt richtet sich an Clusteradministratoren.

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

Dieser Abschnitt richtet sich an Entwickler.

Wenn Sie die OIDC-Konfigurationsdatei von Ihrem Administrator erhalten, 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

Dieser Abschnitt richtet sich an Clusteradministratoren.

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 zum Bereitstellen von Arbeitslasten
• Mehr über OpenID Connect erfahren
• Bereiche und Anforderungen