GKE Identity Service auf Flottenebene konfigurieren

Dieses Dokument richtet sich an Clusteradministratoren oder Anwendungsoperatoren, die GKE Identity Service auf ihren Clustern einrichten. Es enthält eine Anleitung zum Einrichten von GKE Identity Service auf Flottenebene in Ihren Clustern mit Ihrem bevorzugten Identitätsanbieter. 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 des 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 GKE Enterprise-Seite Features auf.

    Zu 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. Wenn Sie Standardeinstellungen auf Flottenebene konfiguriert haben, wird die Konfiguration auf die Standardeinstellung zurückgesetzt. Weitere Informationen finden Sie unter Standardeinstellungen auf Flottenebene konfigurieren.
  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 in einem bestehenden registrierten Cluster bereits eine GKE Identity Service-Konfiguration vorhanden ist, die Sie verwenden möchten, können Sie diese Konfiguration in die ausgewählten Cluster kopieren. Folgen Sie der Anleitung für Ihren Anbieter, wie im nächsten Abschnitt beschrieben, um eine völlig neue Konfiguration zu erstellen.

Anbieterdetails festlegen

Welche Anbieterdetails Sie hinzufügen müssen, hängt vom Typ des Identitätsanbieters ab, den Sie für Ihre Konfiguration verwenden möchten.

OIDC

  1. Wählen Sie Neues OpenID 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 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, bei dem es sich um das Azure AD-Konto handelt, das im Mandanten authentifiziert werden soll.
  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 Anmeldeattribut 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 von Ihrem Plattformadministrator ausgewählt wurden, wenn Sie den Anbieter für GKE Identity Service konfigurieren.

OIDC

  • Geben Sie die Konfigurationsattribute ein:

    • kubectl-Weiterleitungs-URI: 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.
    • 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 zugelassen.
    • 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 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.
    • Nutzeranforderung (optional): Die JWT-Anforderung (Feldname), die Ihr Anbieter zum Identifizieren eines Kontos verwendet. Wenn Sie hier keinen Wert angeben, verwendet GKE Identity Service einen Wert in der Reihenfolge "email", "preferred_username" oder "sub", um die Nutzerdetails abzurufen.
    • 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 zusätzliche Identitätsanbieter anzugeben.

Konfiguration aktualisieren

  • Klicken Sie auf Konfiguration aktualisieren. Dadurch wird bei Bedarf GKE Identity Service installiert (nur bei EKS-Clustern; bei GKE-Clustern 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, in denen Sie eine Datei namens auth-config.yaml mit Ihrer Konfiguration erstellen.

OIDC

Die folgende Datei zeigt sowohl eine oidc-Konfiguration als auch 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 mehrere 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 von Ihrem Plattformadministrator ausgewählt wurden, wenn Sie den Anbieter für GKE Identity Service konfigurieren.

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, die bei der Registrierung von GKE Identity Service bei Ihrem Anbieter zurückgegeben wurde. 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 GKE Identity Service 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
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 werden, normalerweise in der Form „http://localhost:PORT/callback“. URL String
scopes 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 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 Name des Mandanten 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

SAML

Die folgende Datei zeigt eine SAML-Konfiguration:

   apiVersion: authentication.gke.io/v2alpha1
   kind: ClientConfig
   metadata:
     name: default
     namespace: kube-public
   spec:
     authentication:
     - name: NAME
       saml:
         idpEntityID: ENTITY_ID
         idpSingleSignOnURI: SIGN_ON_URI
         idpCertificateDataList: IDP_CA_CERT
         userAttribute: USER_ATTRIBUTE
         groupsAttribute: GROUPS_ATTRIBUTE
         userPrefix: USER_PREFIX
         groupPrefix: GROUP_PREFIX
         attributeMapping:
           ATTRIBUTE_KEY_1 : ATTRIBUTE_CEL_EXPRESSION_1
           ATTRIBUTE_KEY_2 : ATTRIBUTE_CEL_EXPRESSION_2
      certificateAuthorityData: CERTIFICATE_STRING
      preferredAuthentication: PREFERRED_AUTHENTICATION
      server: <>

In der folgenden Tabelle sind die Felder des ClientConfig-saml-Objekts beschrieben. Welche Felder Sie hinzufügen müssen, hängt von Ihrem Identitätsanbieter und den Einrichtungsoptionen ab, die von Ihrem Plattformadministrator ausgewählt wurden, wenn Sie den Anbieter für GKE Identity Service konfigurieren.

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
idpEntityID Ja Die SAML-Entitäts-ID für den SAML-Anbieter, angegeben in einem URI-Format Beispiel: https://www.idp.com/saml. URL String
idpSingleSignOnURI Ja Den SSO-Endpunkt des SAML-Anbieters, angegeben in einem URI-Format. Beispiel: https://www.idp.com/saml/sso. URL String
idpCertificateDataList Ja Entspricht den Identitätsanbietern, die zur Überprüfung der SAML-Antwort verwendet wurden. Diese Zertifikate müssen standardmäßig base64-codiert und PEM-formatiert sein. Es werden nur maximal zwei Zertifikate unterstützt, um die Rotation von Identitätsanbietern zu ermöglichen. String
userAttribute Nein Name des Attributs in der SAML-Antwort, das den Nutzernamen enthält. String
groupsAttribute Nein Name des Attributs in der SAML-Antwort, das die Gruppeninformationen des Nutzers enthält. 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
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
attributeMapping Nein Die Zuordnung zusätzlicher Nutzerattribute. 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
preferredAuthentication Nein Name der bevorzugten Authentifizierungsmethode, die im Cluster konfiguriert ist. 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 sind die Felder des ClientConfig-ldap-Objekts beschrieben. Welche Felder Sie hinzufügen müssen, hängt von Ihrem Identitätsanbieter und den Einrichtungsoptionen ab, die von Ihrem Plattformadministrator ausgewählt wurden, wenn Sie den Anbieter für GKE Identity Service konfigurieren.

Feld Erforderlich Beschreibung Format
Name Ja 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 Ja LDAP-Verbindungstyp, der beim Herstellen einer Verbindung zum LDAP-Server verwendet werden soll. Wenn starttls oder ldaps angegeben ist, sollte 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. Dies 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, um Nutzern die Anmeldung mit einem Nutzernamen zu ermöglichen. Die tatsächliche Kennzeichnung muss jedoch eine E-Mail-Adresse oder ein vollständiger Distinguished Name (DN) sein. Beispiel: Wenn Sie loginAttribute auf sAMAccountName und identifierAttribute auf userPrincipleName setzen, können sich Nutzer als bsmith anmelden. Die tatsächlichen RBAC-Richtlinien für den Nutzer würden jedoch so geschrieben werden: bsmith@example.com. Die Verwendung von userPrincipleName wird empfohlen, da dies für jeden Nutzer eindeutig ist. Wenn nicht angegeben, lautet die Standardeinstellung userPrincipleName. String
group (optionales Feld)
baseDN Ja 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 Der Distinguished Name des Dienstkontonutzers. String
Passwort yes Das Passwort des Dienstkontonutzers. String

GKE Identity Service aktivieren

Sie können 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 in Ihrer Flotte registriert ist. Weitere Informationen zu Standardkonfigurationen auf Flottenebene finden Sie unter Standardkonfigurationen auf Flottenebene konfigurieren. Führen Sie folgenden Befehl aus, um 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 innerhalb der Flotte. Beim Ausführen dieses Befehls wird die Konfiguration vom GKE Identity Service-Controller verwaltet. Alle lokalen Änderungen, die an der Clientkonfiguration von GKE Identity Service vorgenommen werden, werden vom Controller wieder auf die Konfiguration umgestellt, die in dieser Einrichtung festgelegt wurde.

Dadurch kann GKE Identity Service Google Groups-Informationen für Nutzerkonten abrufen, die sich mit ihrer Google-ID anmelden. Diese Konfiguration gilt für GKE on VMware und Google Distributed Cloud Virtual for Bare Metal ab GKE Enterprise 1.13. Weitere Informationen zur Google Groups-Funktion finden Sie unter Connect-Gateway mit Google Groups einrichten.

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 einer GKE Identity Service-Konfiguration auf Flottenebene alle vorhandenen Authentifizierungsspezifikationen überschrieben.
  • Wenn Anbieterkonfigurationen auf Clusterebene vorhanden sind, 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 die Konfiguration nicht mehr mit dem GKE Identity Service-Controller verwalten möchten, z. B. weil Sie andere Authentifizierungsoptionen verwenden möchten, können Sie dieses Feature deaktivieren. Folgen Sie dazu der Anleitung unter Verwaltung von GKE Identity Service deaktivieren.

Anbieterspezifische Konfigurationen

Dieser Abschnitt enthält Konfigurationsanleitungen für OIDC-Anbieter (z. B. Azure AD und Okta), einschließlich einer Beispielkonfiguration, die Sie kopieren und mit Ihren eigenen Details 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 von Azure AD abrufen und die rollenbasierte Zugriffssteuerung (RBAC) von Kubernetes basierend auf Gruppen einrichten. Bei dieser Konfiguration sind Sie jedoch auf ca. 200 Gruppen pro Nutzer beschränkt.

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

...
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 Limit für die Anzahl der 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 Standardkonfiguration mit einem oidc-Anker in Ihrer ClientConfig zu verwenden. Weitere Informationen finden Sie in der Anleitung für Azure AD.

Alle Felder in der Beispielkonfiguration sind erforderlich.

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

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

Ersetzen Sie GROUP_FORMAT durch das Format, in dem Sie Gruppeninformationen abrufen möchten. Dieses Feld kann Werte enthalten, die ID oder NAME der Nutzergruppen entsprechen. Diese Einstellung ist nur für GKE on VMware- und Google Distributed Cloud Virtual for Bare Metal-Cluster verfügbar.

Okta

Im Folgenden wird gezeigt, wie Sie die Authentifizierung mithilfe von Nutzern und Gruppen mit Okta als Identitätsanbieter einrichten. Mit dieser Konfiguration kann 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 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 GKE-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 GKE Identity Service mit einer Standardkonfiguration auf Flottenebene:

  1. Erstellen Sie eine Datei mit dem Namen fleet-default.yaml und füllen Sie sie wie unter Konfigurationsdatei erstellen beschrieben aus.
  2. Aktivieren Sie 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 neue 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 die Standardkonfiguration nicht automatisch. 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 überprüfen

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

Console

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

    Zur GKE Enterprise Feature Management

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

  2. Klicken Sie für das Feature Identity Service auf DETAILS. Im Detailbereich wird der Status Ihrer 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 von 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 GKE Enterprise-Seite Features auf.

    Zu 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

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