GKE Identity Service auf Flottenebene konfigurieren

Dieses Dokument richtet sich an Clusteradministratoren oder Anwendungsoperatoren, die GKE Identity Service auf ihren Clustern einrichten. Darin wird beschrieben, wie Sie den GKE Identity Service auf Flottenebene in Ihren Clustern mit Ihrem bevorzugten OIDC-Identitätsanbieter (OpenID Connect) einrichten. Bei der Anleitung in diesem Dokument wird davon ausgegangen, dass GKE Identity Service bereits als Clientanwendung bei Ihrem Identitätsanbieter registriert ist.

Weitere Informationen zu GKE Identity Service und anderen Einrichtungsoptionen finden Sie in der Übersicht. Informationen zum Zugriff auf einen Cluster mit diesem Dienst als Entwickler oder anderer Clusternutzer finden Sie unter Mit GKE Identity Service auf Cluster zugreifen.

Hinweise

  • Achten Sie darauf, dass Ihr Plattformadministrator alle erforderlichen Informationen unter OIDC-Anbieter für GKE Identity Service konfigurieren bereitgestellt hat, bevor Sie mit der Einrichtung beginnen, einschließlich der Client-ID und des Secrets für GKE Identity Service.
  • Achten Sie darauf, dass die Cluster, die Sie konfigurieren möchten, die Voraussetzungen für die Einrichtung auf Flottenebene erfüllen. Informationen zu anderen Clustertypen und Umgebungen finden Sie in der Übersicht zu GKE Identity Service.
  • Prüfen Sie, ob die folgenden Befehlszeilentools installiert sind:

    • Die neueste Version der Google Cloud CLI, die gcloud, das Befehlszeilentool für die Interaktion mit Google Cloud, enthält. Informationen zur Installation des Google Cloud CLI finden Sie in der Installationsanleitung.
    • kubectl zum Ausführen von Befehlen für Kubernetes-Cluster. Informationen zum Installieren von kubectl finden Sie in der Installationsanleitung.

    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 dem Projekt initialisiert ist, in dem die Cluster registriert sind.

  • Wenn Sie nicht der Projektinhaber sind, benötigen Sie zum Vervollständigen der Konfigurationsschritte die Rolle GKE-Hub-Administrator in dem Projekt, in dem die Cluster registriert sind.

APIs aktivieren

Console

Achten Sie darauf, dass das Projekt ausgewählt ist, in dem die Cluster registriert sind.

  • GKE Hub and Kubernetes Engine APIs aktivieren.

    Aktivieren Sie die APIs

gcloud

Führen Sie den folgenden Befehl aus, um die erforderlichen APIs für die Einrichtung zu aktivieren:

gcloud services enable 
gkehub.googleapis.com
container.googleapis.com

Cluster konfigurieren

Um Ihre Cluster so zu konfigurieren, dass sie den von Ihnen gewählten Anbieter verwenden, müssen Sie bei GKE Identity Service Details über den Identitätsanbieter, die Informationen in den JWT-Tokens, die er zur Identifizierung der Nutzer bereitstellt, und andere Informationen angeben, die bei der Registrierung von GKE Identity Service als Client-Anwendung bereitgestellt werden.

Wenn Ihr Anbieter beispielsweise Identitätstokens mit den folgenden Feldern erstellt, wobei iss der Identitätsanbieter-URI ist, identifiziert sub den Nutzer und groupList listet die Sicherheitsgruppen auf, denen der Nutzer angehört:

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

...Ihre Konfiguration enthält die folgenden entsprechenden Felder:

issueruri: 'https://server.example.com'
username: 'sub'
group: 'groupList'
...

Ihr Plattformadministrator oder die Person, die die Identitäten in Ihrer Organisation verwaltet, sollte Ihnen die meisten Informationen bereitstellen, die Sie zum Erstellen der Konfiguration benötigen. Beispielkonfigurationen für einige häufig verwendete Identitätsanbieter finden Sie unter Anbieterspezifische Konfigurationen.

Mit GKE Identity Service können Sie diese Konfiguration über die Google Cloud Console oder die Google Cloud CLI erstellen oder aktualisieren.

Console

GKE Identity Service aktivieren

  1. Rufen Sie in der Google Cloud Console die Seite Features von GKE Enterprise auf.

    Zu den GKE Enterprise-Features

  2. In der Tabelle Produkte klicken Sie in der Zeile GKE Identity Service auf Aktivieren und im daraufhin angezeigten Bereich noch einmal auf Aktivieren. Dadurch wird eine neue GKE Identity Service-Controller-Instanz erstellt, um den Lebenszyklus von GKE Identity Service in den Clustern Ihrer Flotte zu verwalten.

Cluster auswählen

  1. Klicken Sie in der Tabelle Produkte in der Zeile GKE Identity Service auf Details, um den Detailbereich für den Dienst zu öffnen. Hier werden die Cluster Ihres Projekts und der Status ihres GKE Identity Service auf Flottenebene angezeigt.
  2. Klicken Sie auf Identitätsdienst aktualisieren, um den Einrichtungsbereich zu öffnen.
  3. Wählen Sie die Cluster aus, die Sie konfigurieren möchten. Es können nur unterstützte Clustertypen ausgewählt werden. Sie können einzelne Cluster auswählen oder festlegen, dass alle Cluster mit derselben Identitätskonfiguration konfiguriert werden sollen.
  4. Wählen Sie im Drop-down-Menü Identitätsanbieter aus, wie Sie die Cluster konfigurieren möchten. Wenn im Cluster bereits eine GKE Identity Service-Konfiguration vorhanden ist, können Sie diese aktualisieren. Wenn ein vorhandener registrierter Cluster eine GKE Identity Service-Konfiguration hat, die Sie verwenden möchten, können Sie diese Konfiguration in die ausgewählten Cluster kopieren. Wenn Sie eine völlig neue Konfiguration erstellen möchten, folgen Sie der Anleitung für Ihren Anbieter, wie im nächsten Abschnitt beschrieben.

Anbieterdetails festlegen

Die Anbieterdetails, die Sie hinzufügen müssen, hängen vom Identitätsanbietertyp ab, den Sie für die Konfiguration verwenden möchten.

OIDC

  1. Wählen Sie New Open ID Connect aus, um eine neue OIDC-Konfiguration zu erstellen.
  2. Geben Sie im Feld Anbietername den Namen an, den Sie verwenden möchten, um diese Konfiguration zu identifizieren. Dies ist in der Regel der Name des Identitätsanbieters. Der Name muss mit einem Buchstaben beginnen, gefolgt von bis zu 39 Kleinbuchstaben, Ziffern oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein. Sie können diesen Namen nicht mehr bearbeiten, nachdem Sie eine Konfiguration erstellt haben.
  3. Geben Sie im Feld Client-ID die Client-ID an, die bei der Registrierung von GKE Identity Service bei Ihrem Dienstanbieter zurückgegeben wurde.
  4. Geben Sie im Feld Client-Secret die Clientschlüssel an, die von der Clientanwendung und dem Identitätsanbieter gemeinsam verwendet werden müssen.
  5. Geben Sie im Feld Aussteller-URL den URI an, über den Autorisierungsanfragen an Ihren Identitätsanbieter gesendet werden.
  6. Klicken Sie auf Weiter, um die OIDC-Attribute festzulegen.

Azure AD

  1. Wählen Sie New Azure Active Directory (Neues Azure Active Directory) aus, um eine neue Azure AD-Konfiguration zu erstellen.
  2. Geben Sie im Feld Anbietername den Namen an, den Sie verwenden möchten, um diese Konfiguration zu identifizieren. Dies ist in der Regel der Name des Identitätsanbieters. Der Name muss mit einem Buchstaben beginnen, gefolgt von bis zu 39 Kleinbuchstaben, Ziffern oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein. Sie können diesen Namen nicht mehr bearbeiten, nachdem Sie eine Konfiguration erstellt haben.
  3. Geben Sie im Feld Client-ID die Client-ID an, die bei der Registrierung von GKE Identity Service bei Ihrem Dienstanbieter zurückgegeben wurde.
  4. Geben Sie im Feld Client-Secret die Clientschlüssel an, die von der Clientanwendung und dem Identitätsanbieter gemeinsam verwendet werden müssen.
  5. Geben Sie den Mandanten an, der das zu authentifizierende Azure AD-Konto im Mandanten ist.
  6. Klicken Sie auf Weiter, um die Azure AD-Attribute festzulegen.

LDAP

  1. Wählen Sie LDAP aus, um eine neue LDAP-Konfiguration zu erstellen.
  2. Geben Sie im Feld Anbietername den Namen an, den Sie verwenden möchten, um diese Konfiguration zu identifizieren. Dies ist in der Regel der Name des Identitätsanbieters. Der Name muss mit einem Buchstaben beginnen, gefolgt von bis zu 39 Kleinbuchstaben, Ziffern oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein. Sie können diesen Namen nicht mehr bearbeiten, nachdem Sie eine Konfiguration erstellt haben.
  3. Klicken Sie auf Next (Weiter).
  4. Geben Sie den Hostnamen (erforderlich), den LDAP-Verbindungstyp und das base64-codierte CA-Zertifikat des LDAP-Servers an.
  5. Klicken Sie auf Weiter, um den Server zu konfigurieren.
  6. Geben Sie den Distinguished Name, den Filter, das Anmelde- und das ID-Attribut des Nutzers an.
  7. Klicken Sie auf Weiter, um die Nutzerdetails festzulegen.
  8. Wenn Sie Gruppen verwenden, geben Sie den Distinguished Name, den Filter und das ID-Attribut der Gruppe an.
  9. Klicken Sie auf Weiter, um die Gruppendetails festzulegen.
  10. Geben Sie den Nutzernamen und das Passwort für das Dienstkonto an.
  11. Klicken Sie auf Fertig, um den Namen des Dienstkontos festzulegen.

Attribute festlegen

Welche Attribute Sie hinzufügen müssen, hängt von Ihrem Identitätsanbieter und den Einrichtungsoptionen ab, die Ihr Plattformadministrator bei der Konfiguration des Anbieters für GKE Identity Service ausgewählt hat.

OIDC

  • Geben Sie die Konfigurationsattribute ein:

    • kubectl-Weiterleitungs-URI: Die Weiterleitungs-URL und der Port, die von der gcloud CLI verwendet und von Ihrem Plattformadministrator bei der Registrierung angegeben wurden, in der Regel im Format http://localhost:PORT/callback.
    • Zertifizierungsstelle (optional): Ein von Ihrem Plattformadministrator bereitgestellter PEM-codierter Zertifikatstring für den Identitätsanbieter.
    • Gruppenanforderung (optional): Die JWT-Anforderung (Feldname), die der Anbieter zum Zurückgeben der Sicherheitsgruppen eines Kontos verwendet.
    • Gruppenpräfix (Optional): Das Präfix, das Sie Namen von Sicherheitsgruppen 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).
    • Proxy (optional): Proxyserver-Adresse, die zum Herstellen einer Verbindung mit dem Identitätsanbieter verwendet werden soll (falls zutreffend). 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
    • Bereiche (optional): Alle weiteren für Ihren Identitätsanbieter erforderlichen Bereiche. Microsoft Azure und Okta benötigen den Bereich offline_access. Klicken Sie gegebenenfalls auf Bereich hinzufügen, um weitere Bereiche hinzuzufügen.
    • Nutzeranforderung (optional): Die JWT-Anforderung (Feldname), die Ihr Anbieter zum Identifizieren eines Kontos verwendet. Wenn Sie hier keinen Wert angeben, verwendet GKE Identity Service „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.
    • Nutzerpräfix (optional): Das Präfix, das Sie Nutzeranforderungen voranstellen möchten, um Konflikte mit vorhandenen Namen zu vermeiden, wenn Sie nicht das Standardpräfix verwenden möchten.
    • Zusätzliche Parameter (optional): Alle zusätzlichen Parameter, die für die Konfiguration erforderlich sind. Sie werden als Parameter Key und Value angegeben. Klicken Sie auf Parameter hinzufügen, um bei Bedarf weitere Parameter hinzuzufügen.
    • Zugriffstoken aktivieren (optional): Wenn diese Option aktiviert ist, werden Gruppenunterstützung für OIDC-Anbieter wie Okta ermöglicht.
    • Google Cloud Console-Proxy bereitstellen (optional): Wenn diese Option aktiviert ist, wird ein Proxy bereitgestellt, mit dem die Google Cloud Console eine Verbindung zu einem lokalen Identitätsanbieter herstellen kann, der nicht über das Internet öffentlich zugänglich ist.

Azure AD

  • Geben Sie die Konfigurationsattribute ein:

    • kubectl-Weiterleitungs-URI: Die Weiterleitungs-URL und der Port, die von der gcloud CLI verwendet und von Ihrem Plattformadministrator bei der Registrierung angegeben wurden, in der Regel im Format http://localhost:PORT/callback.
    • Proxy (optional): Proxyserver-Adresse, die zum Herstellen einer Verbindung mit dem Identitätsanbieter verwendet werden soll (falls zutreffend). 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

Identitätsanbieter hinzufügen

  • Wenn Sie zusätzliche Identitätsanbieter haben, die Sie für Ihren Gerätepool konfigurieren möchten, können Sie hier die Anbieter hinzufügen. Führen Sie die Schritte aus, um weitere Identitätsanbieter anzugeben.

Konfiguration aktualisieren

  • Klicken Sie auf Konfiguration aktualisieren. Dadurch wird bei Bedarf der GKE Identity Service installiert (nur für EKS-Cluster, bei GKE Identity Service ist GKE Identity Service bereits standardmäßig installiert) und die Clientkonfiguration wird auf die ausgewählten Cluster angewendet.

gcloud

Konfigurationsdatei erstellen

GKE Identity Service verwendet für die Clusterkonfiguration den benutzerdefinierten Kubernetes-Ressourcentyp „ClientConfig“ mit Feldern, die alle Informationen enthalten, die GKE Identity Service für die Interaktion mit dem Identitätsanbieter haben muss. In den folgenden Abschnitten finden Sie die Konfigurationen für OIDC und LDAP, bei denen Sie eine Datei namens auth-config.yaml mit Ihrer Konfiguration erstellen.

OIDC

Die folgende Datei zeigt eine oidc-Konfiguration und eine azuread-Konfiguration. Weitere Informationen zur Verwendung von oidc oder azuread finden Sie unter Anbieterspezifische Konfigurationen.

  apiVersion: authentication.gke.io/v2alpha1
  kind: ClientConfig
  metadata:
    name: default
    namespace: kube-public
  spec:
    authentication:
    - name: NAME
      proxy: PROXY_URL
      oidc:
        certificateAuthorityData: CERTIFICATE_STRING
        clientID: CLIENT_ID
        clientSecret: CLIENT_SECRET
        deployCloudConsoleProxy: PROXY_BOOLEAN
        extraParams: EXTRA_PARAMS
        groupsClaim: GROUPS_CLAIM
        groupPrefix: GROUP_PREFIX
        issuerURI: ISSUER_URI
        kubectlRedirectURI: http://localhost:PORT/callback
        scopes: SCOPES
        userClaim: USER_CLAIM
        userPrefix: USER_PREFIX

    - name: NAME
      proxy: PROXY_URL
      azureAD:
        clientID: CLIENT_ID
        clientSecret: CLIENT_SECRET
        tenant: TENANT_UUID
        kubectlRedirectURI: http://localhost:PORT/callback

Wenn Sie mehr als einen Identitätsanbieter konfiguriert haben, können Sie mehrere Authentifizierungskonfigurationen in der Datei auth-config.yaml unter dem Anker authentication im selben Format wie in der vorherigen Konfiguration auflisten.

In der folgenden Tabelle sind die Felder des ClientConfig-oidc- und azuread-Objekts beschrieben. Die meisten Felder sind optional. Welche Felder Sie hinzufügen müssen, hängt von Ihrem Identitätsanbieter und den Einrichtungsoptionen ab, die Ihr Plattformadministrator bei der Konfiguration des Anbieters für GKE Identity Service ausgewählt hat.

Feld Erforderlich Beschreibung Format
Name yes 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, die bei der Registrierung des GKE Identity Service bei Ihrem Anbieter zurückgegeben wird. String
clientSecret Ja Das Client-Secret, das bei der Registrierung von GKE Identity Service bei Ihrem Anbieter zurückgegeben wurde. 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
enableAccessToken Nein Wenn diese Option aktiviert ist, kann der GKE Identity Service den Userinfo-Endpunkt des Identitätsanbieters verwenden, um Gruppeninformationen abzurufen, wenn sich ein Nutzer über die Befehlszeile anmeldet. So können Sie Sicherheitsgruppen für die Autorisierung verwenden, wenn Sie einen Anbieter wie Okta haben, der Gruppenanforderungen von diesem Endpunkt bereitstellt. Wenn nicht festgelegt, wird dies als false betrachtet. Boolesch
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. Für den URI muss HTTPS verwendet werden. URL String
kubectlRedirectURI Ja Die Weiterleitungs-URL und der Port, die von der gcloud CLI verwendet und von Ihrem Plattformadministrator bei der Registrierung angegeben wurden, in der Regel im Format „http://localhost:PORT/callback“. URL String
scopes Ja Zusätzliche Bereiche, die an den OpenID-Anbieter gesendet werden. Für Microsoft Azure und Okta ist beispielsweise der Bereich offline_access erforderlich. Durch Kommas getrennte Liste
userClaim Nein Die JWT-Anforderung (Feldname), die Ihr Anbieter zur Identifizierung eines Nutzerkontos verwendet. Wenn Sie hier keinen Wert angeben, verwendet GKE Identity Service „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
Mandant Ja Die Art des zu authentifizierenden Azure AD-Kontos. Unterstützte Werte sind die Mandanten-ID oder der Mandantenname für Konten, die zu einem bestimmten Mandanten gehören. Der Mandantenname wird auch als primäre Domain bezeichnet. Weitere Informationen zum Ermitteln dieser Werte finden Sie unter Microsoft Azure AD-Mandanten-ID und Namen der primären Domain finden. String
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

LDAP

Die folgende Datei zeigt eine ldap-Konfiguration.

  apiVersion: authentication.gke.io/v2alpha1
  kind: ClientConfig
  metadata:
    name: default
    namespace: kube-public
  spec:
    authentication:
    - name: ldap
      ldap:
        server:
          host: HOST_NAME
          connectionType: CONNECTION_TYPE
          certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
        user:
          baseDn: BASE_DN
          loginAttribute: LOGIN_ATTRIBUTE
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE
        group:
          baseDn: BASE_DN
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE
        serviceAccount:
          simpleBindCredentials:
            dn: DISTINGUISHED_NAME
            password: PASSWORD

In der folgenden Tabelle werden die Felder im ClientConfig-Objekt ldap beschrieben. Welche Felder Sie hinzufügen müssen, hängt von Ihrem Identitätsanbieter und den Einrichtungsoptionen ab, die Ihr Plattformadministrator bei der Konfiguration des Anbieters für GKE Identity Service ausgewählt hat:

Feld Erforderlich Beschreibung Format
Name yes Ein Name zur Identifizierung dieser LDAP-Konfiguration String
Server
Host Ja Hostname oder IP-Adresse des LDAP-Servers. Der Port ist optional und standardmäßig 389, wenn nicht angegeben. Beispiel: ldap.server.example.com oder 10.10.10.10:389. String
connectionType yes LDAP-Verbindungstyp, der beim Herstellen einer Verbindung zum LDAP-Server verwendet werden soll. Wenn starttls oder ldaps angegeben ist, darf das Feld „certificateAuthorityData“ nicht leer sein. String
certificateAuthorityData Erforderlich für bestimmte LDAP-Verbindungstypen Enthält ein Base64-codiertes, PEM-formatiertes Zertifizierungsstellen-Zertifikat für den LDAP-Server. Muss nur für ldaps- und startTLS-Verbindungen angegeben werden. String
Nutzer
baseDN Ja Der Speicherort der Unterstruktur im LDAP-Verzeichnis, um nach Nutzereinträgen zu suchen. String im DN-Format.
loginAttribute no Der Name des Attributs, das dem Eingabenutzernamen entspricht. Damit wird der Nutzer in der LDAP-Datenbank gesucht, z. B. (<LoginAttribute>=<username>). Es wird mit dem optionalen Filterfeld kombiniert. Die Standardeinstellung ist userPrincipleName. String
Filter no Optionaler Filter, der bei der Suche nach dem Nutzer angewendet werden soll. Damit können Sie die Nutzerkonten, die sich anmelden dürfen, weiter einschränken. Wenn nicht angegeben, lautet die Standardeinstellung (objectClass=User). String
identifierAttribute no Bestimmt, welches Attribut nach der Authentifizierung als Identität des Nutzers verwendet werden soll. Dies unterscheidet sich vom Feld loginAttribute, damit sich Nutzer mit einem Nutzernamen anmelden können, deren tatsächliche Kennung jedoch eine E-Mail-Adresse oder ein vollständiger Distinguished Name (DN) sein kann. Wenn Sie beispielsweise loginAttribute auf sAMAccountName und „identifierAttribute“ auf userPrincipleName setzen, kann sich ein Nutzer als bsmith anmelden. Tatsächliche RBAC-Richtlinien für den Nutzer würden jedoch als bsmith@example.com geschrieben werden. Die Verwendung von userPrincipleName wird empfohlen, da dies für jeden Nutzer eindeutig ist. Wenn keine Vorgabe erfolgt, wird standardmäßig userPrincipleName verwendet. String
group (optionales Feld)
baseDN yes Der Speicherort der Unterstruktur im LDAP-Verzeichnis, um nach Gruppeneinträgen zu suchen. String
Filter no Optionaler Filter, der bei der Suche nach Gruppen verwendet wird, zu denen ein Nutzer gehört. Dies kann verwendet werden, um explizit auf bestimmte Gruppen einzuschränken, um die Anzahl der Gruppen zu reduzieren, die für jeden Nutzer zurückgegeben werden. Die Standardeinstellung ist (objectClass=Group). String
identifierAttribute no Der identifizierende Name jeder Gruppe, zu der ein Nutzer gehört. Wenn dieser Wert beispielsweise auf distinguishedName festgelegt ist, sollten RBACs und andere Gruppenerwartungen als vollständige DNs geschrieben werden. Wenn nicht angegeben, lautet die Standardeinstellung distinguishedName. String
serviceAccount/simpleBindCredentials
dn yes Distinguished Name des Dienstkontonutzers. String
Passwort yes Das Passwort des Dienstkontonutzers. String

GKE Identity Service aktivieren

Sie können den GKE Identity Service auch mit einer Standardkonfiguration auf Flottenebene aktivieren. Mit dieser Einrichtung wird die von Ihnen angegebene Konfiguration automatisch auf jeden neuen Cluster angewendet, der bei Ihrer Flotte registriert ist. Weitere Informationen zu Standardkonfigurationen auf Flottenebene finden Sie unter Standardkonfigurationen auf Flottenebene konfigurieren.

Führen Sie den folgenden Befehl aus, um den GKE Identity Service für Ihr Projekt zu aktivieren:

gcloud container fleet identity-service enable

Dadurch wird eine neue GKE Identity Service-Controller-Instanz erstellt, um den Lebenszyklus von GKE Identity Service in den Clustern Ihrer Flotte zu verwalten. Sie müssen diesen Befehl nur einmal pro Projekt ausführen, um GKE Identity Service mit allen unterstützten Clustern zu verwenden, die für Ihre Projektflotte registriert sind.

Konfiguration auf einen Cluster anwenden

Um den GKE Identity Service zu installieren (nur bei EKS-Clustern, bei GKE-Clustern ist GKE Identity Service bereits standardmäßig installiert) und die Konfiguration auf einen Cluster anzuwenden, führen Sie den folgenden Befehl aus:

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

Ersetzen Sie CLUSTER_NAME durch den eindeutigen Namen Ihres Clusters in der Flotte.

Nach Anwendung der Clusterkonfiguration wird diese Konfiguration vom GKE Identity Service Controller verwaltet und gilt als „Source of Truth“. Alle lokalen Änderungen an der Konfiguration des GKE Identity Service-Clients werden vom Controller mit der in dieser Einrichtung angegebenen Konfiguration abgeglichen.

Wenn in Ihrem Cluster bereits eine Konfiguration für Authentifizierungsoptionen vorhanden ist, gilt Folgendes:

  • Wenn Sie bereits Konfigurationen auf Clusterebene für OIDC-Anbieter haben, werden durch die Anwendung der GKE Identity Service-Steuerung auf Flottenebene alle vorhandenen Authentifizierungsspezifikationen überschrieben.
  • Wenn Sie bereits Konfigurationen auf Clusterebene für Anbieter haben, die für die Konfiguration auf Flottenebene nicht unterstützt werden, schlägt diese Einrichtung fehl. Sie müssen die vorhandene Anbieterkonfiguration entfernen, um die Konfiguration auf Fleet-Ebene anwenden zu können.

Wenn Sie nicht mehr möchten, dass der GKE Identity Service Controller Ihre Konfiguration verwaltet, z. B. wenn Sie eine andere Authentifizierungsoption oder -optionen verwenden möchten, können Sie diese Funktion deaktivieren. Folgen Sie dazu der Anleitung unter GKE Identity Service-Verwaltung deaktivieren.

Anbieterspezifische Konfigurationen

Dieser Abschnitt enthält Anleitungen zur Konfiguration von OIDC-Anbietern wie Azure AD und Okta, einschließlich einer Beispielkonfiguration, die Sie mit Ihren eigenen Details kopieren und bearbeiten können.

Azure AD

Dies ist die Standardkonfiguration zum Einrichten von GKE Identity Service mit Azure AD. Mit dieser Konfiguration kann GKE Identity Service Nutzer- und Gruppeninformationen aus Azure AD abrufen und Sie können eine rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes auf Basis von Gruppen einrichten. Mit dieser Konfiguration sind Sie jedoch auf ca. 200 Gruppen pro Nutzer beschränkt.

Wenn Sie mehr als 200 Gruppen pro Nutzer abrufen möchten, lesen Sie die Anleitung für Azure AD (Advanced).

...
spec:
  authentication:
  - name: oidc-azuread
    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

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Azure AD (erweitert)

Mit dieser optionalen Konfiguration für Azure AD kann GKE Identity Service Nutzer- und Gruppeninformationen ohne Beschränkung der Anzahl an Gruppen pro Nutzer mithilfe der Microsoft Graph API abrufen. Informationen zu Plattformen, die diese Konfiguration unterstützen, finden Sie unter Erweiterte Einrichtung für Azure AD.

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

Alle Felder in der Beispielkonfiguration sind Pflichtfelder.

...
spec:
  authentication:
  - name: azure
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_UUID
      kubectlRedirectURI: http://localhost:PORT/callback

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Okta

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

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

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Standardeinstellungen auf Flottenebene konfigurieren

Sie können den GKE Identity Service mit einer Standardkonfiguration auf Flottenebene aktivieren. Bei dieser Einrichtung wird für jeden neuen GKE-Cluster in Google Cloud, der während der Clustererstellung registriert wird, oder Anthos-Cluster GKE Identity Service mit der von Ihnen angegebenen Konfiguration auf dem Cluster aktiviert. Weitere Informationen zum Verwalten der Konfiguration auf Flottenebene finden Sie unter Features auf Flottenebene verwalten.

So konfigurieren Sie den GKE Identity Service mit einer Standardkonfiguration auf Flottenebene:

  1. Erstellen Sie eine Datei mit dem Namen fleet-default.yaml und füllen Sie diese wie unter Konfigurationsdatei erstellen beschrieben aus.

  2. Aktivieren Sie den GKE Identity Service mit einer Standardkonfiguration auf Flottenebene:

    gcloud container fleet identity-service enable --fleet-default-member-config=fleet-default.yaml
    
  3. Führen Sie den folgenden Befehl aus, um die vorhandene Standardkonfiguration auf Flottenebene zu ändern oder eine hinzuzufügen, wenn GKE Identity Service in Ihrer Flotte bereits ohne Standardkonfiguration auf Flottenebene aktiviert ist:

    gcloud container fleet identity-service apply --fleet-default-member-config=default-config.yaml
    
  4. Cluster, die vor der Konfiguration der Standardkonfiguration auf Flottenebene registriert wurden, übernehmen nicht automatisch die Standardkonfiguration. Wenn Sie die Standardkonfiguration auf einen Cluster anwenden möchten, der zu dieser Clusterklasse gehört, führen Sie den folgenden Befehl aus:

    gcloud container fleet identity-service apply --origin=fleet --membership=CLUSTER_NAME
    
  5. Führen Sie den folgenden Befehl aus, um die Standardkonfiguration auf Flottenebene zu entfernen:

    gcloud container fleet identity-service delete --fleet-default-member-config
    

Konfiguration des Identitätsdienstes prüfen

Nachdem Sie die Einrichtung auf Flottenebene abgeschlossen haben, können Sie prüfen, ob die Cluster in Ihrer Flotte mit der von Ihnen angegebenen Konfiguration des Identitätsdienstes konfiguriert wurden.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Features von GKE Enterprise auf.

    Zur GKE Enterprise-Funktionsverwaltung

    Aktivierte Funktionen werden in der Liste der Funktionen als Aktiviert aufgeführt.

  2. Klicken Sie bei der Funktion Identity Service auf DETAILS. Im Detailbereich wird der Status der registrierten Cluster angezeigt.

gcloud

Führen Sie dazu diesen Befehl aus:

gcloud container fleet identity-service describe

Nutzerzugriff einrichten

Nachdem Sie die Cluster konfiguriert haben, fahren Sie mit dem Einrichten des Nutzerzugriffs fort.

Verwaltung von GKE Identity Service auf Flottenebene deaktivieren

Wenn Sie nicht möchten, dass Ihre Konfiguration und Ihr Lebenszyklus von GKE Cloud Identity Service verwaltet werden, können Sie dieses Feature deaktivieren. Wenn Sie die Verwaltung auf Flottenebene deaktivieren, werden weder GKE Identity Service noch Ihre Authentifizierungskonfiguration aus dem Cluster entfernt, sodass sich Nutzer weiterhin mit Ihrem konfigurierten externen Identitätsanbieter beim Cluster authentifizieren können. Wenn Sie jedoch lokale manuelle Änderungen am Cluster an der Konfiguration oder den Ressourcen des GKE Identity Service vornehmen, werden diese Änderungen nicht mehr mit einem Status abgeglichen, der einer Single Source of Truth entspricht.

Verwaltung auf Flottenebene für einen Cluster deaktivieren

Führen Sie den folgenden Befehl aus, um die Verwaltung auf Flottenebene für einen Cluster zu deaktivieren:

gcloud container fleet identity-service delete --membership=CLUSTER_NAME

...wobei CLUSTER_NAME der eindeutige Name Ihres Clusters innerhalb der Flotte ist.

Verwaltung auf Flottenebene für eine Flotte deaktivieren

So deaktivieren Sie die Verwaltung des GKE Identity Service auf Flottenebene für Ihre Flotte.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Features von GKE Enterprise auf.

    Zu den GKE Enterprise-Features

  2. Klicken Sie in der Tabelle Produkte in der Zeile GKE Identity Service auf Details und dann im angezeigten Bereich auf GKE Identity Service deaktivieren.

gcloud

Führen Sie dazu diesen Befehl aus:

gcloud container fleet identity-service disable

Nachdem Sie das Produkt für Ihre Flotte deaktiviert haben, können Sie den GKE Identity Service-Status eines Clusters nicht mehr in der Google Cloud Console oder mit gcloud aufrufen oder aktualisieren.

Fehlerbehebung

Wenn bei der Einrichtung Probleme auftreten, finden Sie in der Anleitung zur Fehlerbehebung weitere Informationen.