Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Fleet-Member-Cluster für die OIDC-Authentifizierung einrichten

In diesem Dokument wird beschrieben, wie Clusteradministratoren oder Anwendungsoperatoren Cluster so konfigurieren können, dass die Authentifizierung mit einem OpenID Connect-Anbieter (OIDC) eines Drittanbieters unterstützt wird.

Beschränkungen

Sie müssen einen Clustertyp verwenden, der OIDC unterstützt.

Hinweis

Installieren Sie die Google Cloud CLI.
Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.
Führen Sie den folgenden Befehl aus, um die gcloud CLI zu initialisieren:
```
gcloud init
```
Aktualisieren Sie die gcloud CLI nach der Initialisierung und installieren Sie die erforderlichen Komponenten:
```
gcloud components update
gcloud components install kubectl
```
Achten Sie darauf, dass Ihr Plattformadministrator Ihnen alle erforderlichen Anbieterinformationen gegeben hat. Weitere Informationen finden Sie unter Details zum Identitätsanbieter freigeben.
Wenn Sie sich über die Google Cloud Console authentifizieren möchten, registrieren Sie jeden Cluster den Sie konfigurieren möchten, in Ihrer Projektflotte. Weitere Informationen finden Sie unter Flotten erstellen – Übersicht.
Wenn Sie über einen Bastion Host eine Verbindung zur Steuerungsebene eines AWS- oder Azure-Clusters herstellen müssen, der sich außerhalb Ihres aktuellen VPC-Netzwerk befindet, achten Sie darauf, dass Sie den Bastion Host erstellt und einen SSH-Tunnel an Port 8118 gestartet haben. Wenn Sie in diesem Dokument kubectl Befehle ausführen, stellen Sie den Befehlen HTTPS_PROXY=http://localhost:PORT voran, wobei PORT die Portnummer ist, die Sie beim Starten des SSH-Tunnels verwendet haben.
Registrieren Sie die GKE-Cluster in Ihrer Flotte. Google Cloud

Cluster konfigurieren

Wenn Sie die Authentifizierung für einen Cluster mit OIDC konfigurieren möchten, fügen Sie die folgenden Informationen einer benutzerdefinierten Kubernetes Ressource namens ClientConfig hinzu:

Informationen zu Ihrem Identitätsanbieter, z. B. eine Client-ID und ein Secret.
Informationen zu den JSON-Web-Tokens (JWTs), die Ihr Identitätsanbieter für die Authentifizierung verwendet.
Alle zusätzlichen Bereiche oder Parameter, die für Ihren Identitätsanbieter eindeutig sind.

Weitere Informationen zu den Informationen, die Sie von Ihrem Plattform administrator oder der Person, die die Identitäten in Ihrer Organisation verwaltet, benötigen, finden Sie unter Details zum Identitätsanbieter freigeben.

Der Cluster verwendet die Felder in der benutzerdefinierten ClientConfig-Ressource, um mit Ihrem Identitätsanbieter zu interagieren. Jeder Cluster hat eine ClientConfig namens default im Namespace kube-public. Die spezifischen Felder, die Sie ändern, hängen von Ihrem Identitätsanbieter ab.

Wenn Sie die default ClientConfig bearbeiten möchten, müssen Sie über eine Verbindung zu Ihrem Cluster kubectl herstellen und den folgenden Befehl ausführen:

kubectl --kubeconfig=KUBECONFIG_PATH edit ClientConfigs default -n kube-public

Ersetzen Sie KUBECONFIG_PATH durch den Pfad zur kubeconfig-Datei Ihres Clusters, z. B. $HOME/.kube/config.

Die ClientConfig-Ressource des Clusters wird in einem Texteditor geladen. Fügen Sie das Objekt spec.authentication.oidc wie im folgenden Beispiel hinzu. Ändern Sie keine bereits geschriebenen Standarddaten.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    oidc:
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
      enableAccessToken: ENABLE_ACCESS_TOKEN
    proxy: PROXY_URL
# Rest of the resource is managed by Google. DO NOT MODIFY.

Betrachten Sie beispielsweise die folgenden Felder für Identitätstokens:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  # Multiple lines are omitted here
}

In diesem Beispiel ist iss der URI des Identitätsanbieters, sub identifiziert den Nutzer und groupList listet die Sicherheitsgruppen auf, denen der Nutzer angehört. Dieses Beispiel zeigt nur eine Auswahl der Felder, die das tatsächliche Token haben kann.

Für das vorherige Beispieltoken aktualisieren Sie die folgenden Felder im Objekt spec.authentication.oidc der ClientConfig:

issuerURI: 'https://server.example.com'
userClaim: 'sub'
groupsClaim: 'groupList'
# Multiple lines are omitted here

Sie können derselben ClientConfig mehrere OIDC-, LDAP- und SAML-Identitätsanbieterkonfigurationen hinzufügen. Der Cluster versucht, sich mit jeder Konfiguration in der Reihenfolge zu authentifizieren, in der sie definiert sind, und stoppt nach der ersten erfolgreichen Authentifizierung. In der folgenden Beispiel-ClientConfig werden mehrere Identitätsanbieter in einer bestimmten Reihenfolge definiert:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

ClientConfig-OIDC-Felder

In der folgenden Tabelle sind die Felder des ClientConfig-Objekts oidc beschrieben. Welche Felder Sie hinzufügen müssen, hängt von Ihren Identitätsanbietertokens und davon ab, wie Ihr Plattformadministrator den Anbieter konfiguriert hat.

Feld	Erforderlich	Beschreibung	Format
Name	Ja	Der Name, den Sie dieser Konfiguration zuweisen möchten, normalerweise der Name des Identitätsanbieters. Ein Konfigurationsname muss mit einem Buchstaben beginnen, gefolgt von bis zu 39 Kleinbuchstaben, Zahlen oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein.	String
certificateAuthorityData	Nein	Ein eventuell von Ihrem Plattformadministrator bereitgestellter PEM-codierter Zertifikatstring für den Identitätsanbieter. Fügen Sie den resultierenden String in `certificateAuthorityData` als eine Zeile ein.	String
clientID	Ja	Die Client-ID vom Identitätsanbieter.	String
clientSecret	Nein	Gemeinsames Secret vom OIDC-Clientanwendung und OIDC-Anbieter.	String
deployCloudConsoleProxy	Nein	Gibt an, ob ein Proxy bereitgestellt wird, mit dem die Google Cloud Console eine Verbindung zu einem lokalen Identitätsanbieter herstellen kann, der nicht über das Internet öffentlich zugänglich ist. Standardmäßig ist dies auf `false` eingestellt.	Boolesch
extraParams	Nein	Zusätzliche key=value-Parameter, die als durch Kommas getrennte Liste an den Identitätsanbieter gesendet werden, z. B. `prompt=consent,access_type=offline`.	Durch Kommas getrennte Liste
groupsClaim	Nein	Die JWT-Anforderung (Feldname), die Ihr Anbieter zum Zurückgeben der Sicherheitsgruppen eines Kontos verwendet.	String
groupPrefix	Nein	Das Präfix, das Sie Sicherheitsgruppennamen voranstellen möchten, um Konflikte mit vorhandenen Namen in Ihren Zugriffssteuerungsregeln zu vermeiden, wenn Sie Konfigurationen für mehrere Identitätsanbieter haben (normalerweise der Anbietername).	String
issuerURI	Ja	Der URI, an den Autorisierungsanfragen an Ihren Identitätsanbieter gesendet werden. Der URI muss HTTPS verwenden und darf nicht mit einem nachgestellten Schrägstrich enden.	URL String
kubectlRedirectURI	Ja	Die von der gcloud CLI verwendete Weiterleitungs-URL und der Weiterleitungsport, die von Ihrem Plattformadministrator bei der Registrierung angegeben wurden, normalerweise in der Form `http://localhost:PORT/callback`.	URL String
Umfang	Ja	Zusätzliche Bereiche, die an den OpenID-Anbieter gesendet werden. Microsoft Azure und Okta benötigen beispielsweise den Bereich `offline_access`.	Durch Kommas getrennte Liste
userClaim	Nein	Der JWT-Claim (Feldname), den Ihr Anbieter zur Identifizierung eines Nutzerkontos verwendet. Wenn Sie hier keinen Wert angeben, ist der Standardwert „sub“. Dies ist die Nutzer-ID-Anforderung, die von vielen Anbietern verwendet wird. Je nach OpenID-Anbieter können Sie andere Anforderungen auswählen, beispielsweise „E-Mail“ oder „Name“. Anderen Anforderungen als der E-Mail-Adresse wird die Aussteller-URL vorangestellt, um Namenskonflikte zu vermeiden.	String
userPrefix	Nein	Das Präfix, das Sie den Nutzeranforderungen voranstellen möchten, um Konflikte mit vorhandenen Namen zu vermeiden. Sie können jedoch auch das Standardpräfix verwenden.	String
enableAccessToken	Nein	Wenn diese Option aktiviert ist, kann der Cluster den userinfo-Endpunkt des Identitätsanbieters verwenden, um Gruppeninformationen abzurufen, wenn sich ein Nutzer über die Befehlszeile anmeldet. Dadurch können Sie Sicherheitsgruppen für die Autorisierung verwenden, wenn Sie einen Anbieter wie Okta haben, der Gruppenanforderungen von diesem Endpunkt bereitstellt. Wenn das Feld nicht festgelegt ist, wird der Wert `false` verwendet.	Boolesch
proxy	Nein	Proxyserver-Adresse, die gegebenenfalls zum Herstellen einer Verbindung mit dem Identitätsanbieter verwendet werden soll. 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. Beispiel: `http://user:password@10.10.10.10:8888`.	String

Nachdem Sie die ClientConfig bearbeitet haben, speichern Sie die Datei, um die ClientConfig für Ihren Cluster zu aktualisieren. Bei Syntaxfehlern werden Sie aufgefordert, diese Fehler zu beheben und die Datei zu speichern.

Anbieterspezifische Konfigurationen

Dieser Abschnitt enthält Konfigurationsanleitungen für einige beliebte OIDC-Anbieter, einschließlich Beispielkonfigurationen, die Sie kopieren und mit Ihren eigenen Details bearbeiten können.

Microsoft Entra ID

Dies ist die Standardkonfiguration für die Einrichtung eines Clusters für die Authentifizierung mit Microsoft Entra ID. Mit dieser Konfiguration kann der Cluster Informationen zur Nutzer und Gruppenmitgliedschaft von Microsoft Entra ID abrufen und die Einrichtung der rollenbasierten Zugriffssteuerung (RBAC) von Kubernetes basierend auf Gruppen ermöglichen. Bei dieser Konfiguration können jedoch nur etwa 200 Gruppen pro Nutzer abgerufen werden.

Wenn Sie mehr als 200 Gruppen pro Nutzer abrufen müssen, lesen Sie die Anleitung für Microsoft Entra ID (Erweitert).

# Multiple lines are omitted here.
spec:
  authentication:
  - name: oidc-entraid
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      extraParams: prompt=consent, access_type=offline
      issuerURI: https://login.microsoftonline.com/TENANT_ID/v2.0
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: openid,email,offline_access
      userClaim: email
# Multiple lines are omitted here. Do not modify any pre-filled data.

Ersetzen Sie Folgendes:

CLIENT_ID: Die Client-ID von Microsoft Entra ID.
CLIENT_SECRET: Gemeinsames Secret der OIDC-Clientanwendung und des OIDC-Anbieters.
TENANT_ID: Die Art des zu authentifizierenden Microsoft Entra ID-Kontos. Unterstützte Werte sind die Mandanten-ID oder der Mandantenname für Konten, die zu einem bestimmten Mandanten gehören. Der Name des Mandanten wird auch als primäre Domain bezeichnet. Weitere Informationen zum Ermitteln dieser Werte finden Sie unter Microsoft Entra-Mandanten-ID und Namen der primären Domain finden.
PORT: Die Portnummer, die für die von der gcloud CLI verwendete Weiterleitungs-URL ausgewählt und von Ihrem Plattformadministrator bei der Registrierung angegeben wurde.

Microsoft Entra ID (Erweitert)

Mit dieser optionalen Konfiguration für Microsoft Entra ID kann der Cluster Nutzer- und Gruppeninformationen mit unbegrenzter Anzahl von Gruppen pro Nutzer über die Microsoft Graph API abrufen.

Informationen zu Plattformen, die diese Konfiguration unterstützen, finden Sie unter Erweiterte Einrichtung für Microsoft Entra ID.

Wenn Sie weniger als 200 Gruppen pro Nutzer abrufen müssen, empfehlen wir die Verwendung der Standardkonfiguration mit einem oidc-Anchor in Ihrer ClientConfig. Weitere Informationen finden Sie in der Anleitung für Microsoft Entra ID.

Alle Felder in der folgenden Beispielkonfiguration sind erforderlich.

# Multiple lines are omitted here.
spec:
  authentication:
  - name: NAME
    proxy: PROXY_URL
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_ID
      kubectlRedirectURI: http://localhost:PORT/callback
      groupFormat: GROUP_FORMAT
      userClaim: USER_CLAIM
# Multiple lines are omitted here. Do not modify any pre-filled data.

Ersetzen Sie Folgendes:

NAME: Der Name, den Sie dieser Konfiguration zuweisen möchten, normalerweise der Name des Identitätsanbieters. Ein Konfigurationsname muss mit einem Buchstaben beginnen, gefolgt von bis zu 39 Kleinbuchstaben, Zahlen oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein.
PROXY_URL: Proxyserver-Adresse, die gegebenenfalls zum Herstellen einer Verbindung mit dem Identitätsanbieter verwendet werden soll. 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. Beispiel: http://user:password@10.10.10.10:8888.
CLIENT_ID: Die Client-ID von Microsoft Entra ID.
CLIENT_SECRET: Gemeinsames Secret der OIDC-Clientanwendung und des OIDC-Anbieters.
TENANT: Die Art des zu authentifizierenden Microsoft Entra-Kontos. Unterstützte Werte sind die Mandanten-ID oder der Mandantenname für Konten, die zu einem bestimmten Mandanten gehören. Der Name des Mandanten wird auch als primäre Domain bezeichnet. Weitere Informationen zum Ermitteln dieser Werte finden Sie unter Microsoft Entra-Mandanten-ID und Namen der primären Domain finden.
PORT: Die Portnummer, die für die von der gcloud CLI verwendete Weiterleitungs-URL ausgewählt und von Ihrem Plattformadministrator bei der Registrierung angegeben wurde.
GROUP_FORMAT: Das Format, in dem Sie Gruppeninformationen abrufen möchten. Dieses Feld kann Werte haben, die der ID oder dem NAME der Nutzergruppen entsprechen. Beachten Sie, dass diese Einstellung nur für Cluster in Bare-Metal-Bereitstellungen von Google Distributed Cloud verfügbar ist.
USER_CLAIM (Optional): Die JWT-Anforderung (Feldname), die Ihr Anbieter zur Identifizierung eines Kontos verwendet. Wenn Sie hier keinen Wert angeben, verwendet der Cluster einen Wert in der Reihenfolge „email“, „preferred_username“ oder „sub“, um die Nutzerdetails abzurufen. Dieses Attribut kann ab Version 1.28 verwendet werden.

Okta

Im Folgenden wird gezeigt, wie Sie die Authentifizierung mithilfe von Nutzern und Gruppen mit Okta als Identitätsanbieter einrichten. Mit dieser Konfiguration kann der Cluster Nutzer- und Gruppenanforderungen mithilfe eines Zugriffstokens und des userinfo-Endpunkts von Okta abrufen.

# Multiple lines are omitted here.
spec:
  authentication:
  - name: okta
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      enableAccessToken: true
      extraParams: prompt=consent
      groupsClaim: groups
      issuerURI: https://OKTA_ISSUER_URI/
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: offline_access,email,profile,groups
      userClaim: email
# Multiple lines are omitted here. Do not modify any pre-filled data.

Einschränkungen für den Gruppenzugriff

Bei Okta-Nutzern kann der Cluster Gruppeninformationen für Nutzer abrufen, deren Gruppennamen zusammengenommen (verkettet) eine Länge von weniger als 170.000 Zeichen haben. In Anbetracht der maximalen Gruppenlänge in Okta entspricht dies einer Mitgliedschaft in etwa 650 Gruppen. Wenn der Nutzer Mitglied in zu vielen Gruppen ist, schlägt der Authentifizierungsaufruf fehl.

Nächste Schritte

Nachdem die Konfiguration angewendet wurde, richten Sie den Nutzerzugriff auf Cluster ein.