Konfiguration der Identitätsverwaltung

In diesem Thema wird erläutert, wie Sie die Identitätsverwaltung in Tanzu Kubernetes Grid (TKG) mit einem eigenständigen Verwaltungscluster aktivieren und konfigurieren.

Informationen zum Aktivieren und Konfigurieren der Identitätsverwaltung

Sie können die Identitätsverwaltung während oder nach der Bereitstellung des Verwaltungsclusters aktivieren, indem Sie einen LDAPS- oder OIDC-Identitätsanbieter konfigurieren. Alle Arbeitslastcluster, die Sie nach der Aktivierung der Identitätsverwaltung erstellen, werden automatisch so konfiguriert, dass sie denselben Identitätsanbieter wie der Verwaltungscluster verwenden. Um vorhandene Arbeitslastcluster rückwirkend mit neu aktivierter Identitätsverwaltung zu konfigurieren, führen Sie die Schritte unter Aktivieren der Identitätsverwaltung auf Arbeitslastclustern aus.

Die Aktivierung und Konfiguration der Identitätsverwaltung umfasst die folgenden Schritte. Wenn Sie standardmäßige, nicht administrative kubeconfig-Dateien für den Zugriff auf Verwaltungs- und Arbeitslastcluster verwenden möchten, müssen Sie nach Abschluss der Schritte in diesem Thema auch die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) konfigurieren, indem Sie die Anweisungen in Konfigurieren von RBAC befolgen.

(Empfohlen) Aktivieren und Konfigurieren der Identitätsverwaltung während der Bereitstellung des Verwaltungsclusters:

1. Rufen Sie die Details Ihres Identitätsanbieters ab.
2. Verwenden Sie die erhaltenen Details, um LDAPS oder OIDC in Tanzu Kubernetes Grid zu konfigurieren.
3. Nachdem der Verwaltungscluster erstellt wurde, stellen Sie sicher, dass der Authentifizierungsdienst ordnungsgemäß ausgeführt wird, und schließen Sie die Konfiguration ab.

Anweisungen finden Sie nachstehend unter (Empfohlen) Aktivieren und Konfigurieren der Identitätsverwaltung während der Bereitstellung des Verwaltungsclusters.

Aktivieren und Konfigurieren der Identitätsverwaltung nach der Bereitstellung des Verwaltungsclusters:

1. Rufen Sie die Details Ihres Identitätsanbieters ab.
2. Generieren Sie den geheimen Pinniped-Add-on-Schlüssel für den Verwaltungscluster.
3. Bestätigen Sie, dass der Authentifizierungsdienst ordnungsgemäß ausgeführt wird, und schließen Sie die Konfiguration ab.
4. Wenn der Verwaltungscluster Arbeitslastcluster verwaltet, generieren Sie den geheimen Pinniped-Add-on-Schlüssel für jeden Arbeitslastcluster, der vor der Aktivierung der Identitätsverwaltung erstellt wurde.

Anweisungen finden Sie nachstehend unter Aktivieren und Konfigurieren der Identitätsverwaltung in einer vorhandenen Bereitstellung.

(Empfohlen) Aktivieren und Konfigurieren der Identitätsverwaltung während der Bereitstellung des Verwaltungsclusters

In diesem Abschnitt wird erläutert, wie Sie die Identitätsverwaltung während der Bereitstellung des Verwaltungsclusters aktivieren und konfigurieren können.

Abrufen der Details Ihres Identitätsanbieters

Bevor Sie die Identitätsverwaltung aktivieren können, müssen Sie über einen Identitätsanbieter verfügen. Tanzu Kubernetes Grid unterstützt LDAPS- und OIDC-Identitätsanbieter.

• Um den internen LDAPS-Server Ihres Unternehmens als Identitätsanbieter zu verwenden, beziehen Sie LDAPS-Informationen von Ihrem LDAP-Administrator.
• Um OIDC als Identitätsanbieter zu verwenden, müssen Sie über ein Konto bei einem Identitätsanbieter verfügen, der den OpenID Connect-Standard unterstützt, z. B. Okta.

Beispiel: Registrieren einer Tanzu Kubernetes Grid-Anwendung in Okta

Um Okta als Ihren OIDC-Anbieter zu verwenden, müssen Sie ein Konto bei Okta erstellen und eine Anwendung für Tanzu Kubernetes Grid mit Ihrem Konto registrieren:

1. Wenn Sie noch keines haben, erstellen Sie ein Okta-Konto.
2. Wechseln Sie zum Admin-Portal, indem Sie auf die Schaltfläche Admin klicken.
3. Navigieren Sie zu „Anwendungen (Applications)“ und klicken Sie auf Anwendung hinzufügen (Add Application).
4. Klicken Sie auf Neue App erstellen (Create New App).
5. Wählen Sie für Plattform (Platform) die Option Web aus und wählen Sie als Anmeldemethode (Sign on method) die Option OpenID Connect aus. Klicken Sie dann auf Erstellen (Create).
6. Legen Sie einen Namen für Ihre Anwendung fest.
7. Geben Sie einen Platzhalter für den Umleitungs-URI für die Anmeldung (Login redirect URI) ein. Geben Sie beispielsweise http://localhost:8080/callback ein. Sie aktualisieren diesen Platzhalter mit der realen URL, nachdem Sie den Verwaltungscluster bereitgestellt haben.
8. Klicken Sie auf Speichern.
9. Kopieren und speichern Sie auf der Registerkarte Allgemein (General) für Ihre Anwendung die Client-ID (Client ID) und den Geheimen Clientschlüssel (Client Secrect). Sie benötigen diese Anmeldedaten, wenn Sie den Verwaltungscluster bereitstellen.
10. Weisen Sie der Anwendung auf der Registerkarte Zuweisungen (Assignments) Personen und Gruppen zu. Die Personen und Gruppen, die Sie der Anwendung zuweisen, sind die Benutzer, die auf den Verwaltungscluster und die Arbeitslastcluster zugreifen können, die Sie für die Bereitstellung verwenden.

Konfigurieren von LDAPS- oder OIDC-Einstellungen in Tanzu Kubernetes Grid

Verwenden Sie die oben abgerufenen Details, um LDAPS oder OIDC in Tanzu Kubernetes Grid zu konfigurieren:

• Wenn Sie Ihren Verwaltungscluster über die Benutzeroberfläche des Installationsprogramms bereitstellen, konfigurieren Sie LDAPS oder OIDC im Abschnitt Identitätsverwaltung (Identity Management). Anweisungen finden Sie unter Konfigurieren der Identitätsverwaltung in Bereitstellen von Verwaltungsclustern mit der Installationsprogramm-Schnittstelle.

• Wenn Sie Ihren Verwaltungscluster über eine Konfigurationsdatei bereitstellen, legen Sie die Variablen LDAP_* oder OIDC_* in der Konfigurationsdatei fest.

  Beispiel:

  LDAP:

  IDENTITY_MANAGEMENT_TYPE: ldap
  LDAP_BIND_DN: ""
  LDAP_BIND_PASSWORD: ""
  LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
  LDAP_GROUP_SEARCH_FILTER: (objectClass=posixGroup)
  LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: memberUid
  LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
  LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
  LDAP_HOST: ldaps.example.com:636
  LDAP_ROOT_CA_DATA_B64: ""
  LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
  LDAP_USER_SEARCH_FILTER: (objectClass=posixAccount)
  LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid
  LDAP_USER_SEARCH_USERNAME: uid
  

  OIDC:

  IDENTITY_MANAGEMENT_TYPE: oidc
  OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
  OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
  OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
  OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
  OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email
  OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email
  

  Anweisungen zur Vorbereitung einer Konfigurationsdatei für den Verwaltungscluster finden Sie unter Erstellen einer Konfigurationsdatei für den Verwaltungscluster.

Hinweis

Die Dex-Pods müssen jedes Mal manuell rotiert werden, wenn das Dex-TLS-Zertifikat abläuft (standardmäßig 90 Tage). Sie können die Zertifikatsdauer mithilfe von CERT_DURATION erhöhen. Um die Dex-Pods neu zu starten, führen Sie kubectl rollout restart deployments/dex -n tanzu-system-auth aus.

Abschließen der Konfiguration der Identitätsverwaltung

Nachdem der Verwaltungscluster bereitgestellt wurde, schließen Sie die Konfiguration der Identitätsverwaltung mithilfe der folgenden Verfahren ab, die in den nachstehenden Abschnitten beschrieben werden:

1. Verbinden Sie kubectl mit dem Verwaltungscluster.
2. Bestätigen Sie, dass der Authentifizierungsdienst ordnungsgemäß ausgeführt wird, indem Sie seinen Status überprüfen:
   • OIDC: Überprüfen Sie den Status eines OIDC-Identitätsverwaltungsdiensts.
   • LDAP: Überprüfen Sie den Status eines LDAP-Identitätsverwaltungsdiensts.
3. OIDC: Geben Sie den Callback-URI für den OIDC-Anbieter an.
4. Um die Verwendung standardmäßiger, nicht administrativer kubeconfig-Dateien für den Zugriff auf den Verwaltungscluster zu unterstützen, führen Sie die Schritte unter Konfigurieren von RBAC für einen Verwaltungscluster aus.

kubectl mit dem Verwaltungscluster verbinden

Um die Identitätsverwaltung zu konfigurieren, müssen Sie den admin-Kontext des Verwaltungsclusters abrufen und verwenden:

1. Rufen Sie den admin-Kontext des Verwaltungsclusters ab. Bei den Verfahren in diesem Thema wird ein Verwaltungscluster mit dem Namen id-mgmt-test verwendet.

   tanzu mc kubeconfig get id-mgmt-test --admin
   

   Wenn Ihr Verwaltungscluster den Namen id-mgmt-test hat, sollte die folgende Bestätigung angezeigt werden: Credentials of workload cluster 'id-mgmt-test' have been saved. You can now access the cluster by running 'kubectl config use-context id-mgmt-test-admin@id-mgmt-test'. Der admin-Kontext eines Clusters bietet Ihnen vollständigen Zugriff auf den Cluster, ohne dass eine Authentifizierung bei Ihrem IDP erforderlich ist.

2. Legen Sie kubectl auf den admin-Kontext des Verwaltungsclusters fest:

   kubectl config use-context id-mgmt-test-admin@id-mgmt-test
   

Überprüfen des Status eines OIDC-Identitätsverwaltungsdiensts

Tanzu Kubernetes Grid verwendet Pinniped, um Cluster mit einem OIDC-Identitätsdienst zu vernetzen. Wenn Sie OIDC aktivieren, erstellt Tanzu Kubernetes Grid den pinniped-supervisor-Dienst im pinniped-supervisor-Namespace und pinniped-concierge im pinniped-concierge-Namespace. Führen Sie die folgenden Schritte aus, um den Status des Pinniped-Diensts zu überprüfen, und notieren Sie sich die Adresse EXTERNAL-IP, unter der der Dienst verfügbar ist.

1. Ruft Informationen zu den Diensten ab, die im Verwaltungscluster ausgeführt werden. Der Identitätsverwaltungsdienst wird im pinniped-supervisor-Namespace ausgeführt:

   kubectl get all -n pinniped-supervisor
   

   Ihnen wird der folgende Eintrag in der Ausgabe angezeigt:

   vSphere mit NSX Advanced Load Balancer (ALB):

   NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
   service/pinniped-supervisor   LoadBalancer   100.70.70.12   20.52.230.18   5556:31234/TCP   84m
   

   Amazon Web Services (AWS):

   NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP                              PORT(S)         AGE
   service/pinniped-supervisor   LoadBalancer   100.69.13.66   ab1[...]71.eu-west-1.elb.amazonaws.com   443:30865/TCP   56m
   

   Azure:

   NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)         AGE
   service/pinniped-supervisor   LoadBalancer   100.69.169.220   20.54.226.44     443:30451/TCP   84m
   

   vSphere ohne NSX ALB:

   NAME                          TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
   service/pinniped-supervisor   NodePort   100.70.70.12   <none>        5556:31234/TCP   84m
   

2. Beachten Sie die folgenden Informationen:

   • vSphere mit NSX ALB, AWS und Azure: Notieren Sie sich die externe Adresse des pinniped-supervisor-Diensts, wie unter EXTERNAL-IP aufgeführt.
   • vSphere ohne NSX ALB: Notieren Sie sich den Port, auf dem der pinniped-supervisor-Dienst ausgeführt wird. Im obigen Beispiel ist dieser Port 31234.

3. Stellen Sie sicher, dass alle Dienste im Verwaltungscluster ausgeführt werden.

   kubectl get pods -A
   

   Es kann einige Minuten dauern, bis der Pinniped-Dienst ausgeführt wird. In AWS- und Azure-Bereitstellungen muss der Dienst beispielsweise warten, bis die IP-Adressen des LoadBalancer bereit sind. Warten Sie, bis pinniped-post-deploy-job abgeschlossen ist, bevor Sie mit den nächsten Schritten fortfahren.

   NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
   [...]
   pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
   

Hinweis

Sie können kubectl get pods ausführen, da Sie den admin-Kontext für den Verwaltungscluster verwenden. Benutzer, die versuchen, eine Verbindung mit dem Verwaltungscluster mit dem regulären Kontext herzustellen, können nicht auf dessen Ressourcen zugreifen, da sie noch nicht dazu berechtigt sind.

Überprüfen des Status eines LDAP-Identitätsverwaltungsdiensts

Tanzu Kubernetes Grid nutzt Pinniped, um Cluster mit einem LDAP-Identitätsdienst zu vernetzen, sowie Dex zur Bereitstellung des Dienst-Endpoints. Wenn Sie LDAP aktivieren, erstellt Tanzu Kubernetes Grid den pinniped-supervisor-Dienst im pinniped-supervisor-Namespace, pinniped-concierge im pinniped-concierge-Namespace und dexsvc im tanzu-system-auth-Namespace. Führen Sie die folgenden Schritte aus, um den Status eines LDAP-Diensts zu überprüfen, und notieren Sie sich die Adresse EXTERNAL-IP, unter der der Dienst verfügbar ist.

1. Rufen Sie Informationen zu den Diensten ab, die im Verwaltungscluster im tanzu-system-auth-Namespace ausgeführt werden:

   kubectl get all -n tanzu-system-auth
   

   Ihnen wird der folgende Eintrag in der Ausgabe angezeigt:

   vSphere mit NSX ALB:

   NAME             TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
   service/dexsvc   LoadBalancer   100.70.70.12   20.52.230.18   443:30167/TCP   84m
   

   AWS:

   NAME             TYPE           CLUSTER-IP       EXTERNAL-IP                              PORT(S)         AGE
   service/dexsvc   LoadBalancer   100.65.184.107   a6e[...]74.eu-west-1.elb.amazonaws.com   443:32547/TCP   84m
   

   Azure:

   NAME             TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
   service/dexsvc   LoadBalancer   100.69.169.220   20.54.226.44  443:30451/TCP   84m
   

   vSphere ohne NSX ALB:

   NAME             TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
   service/dexsvc   NodePort   100.70.70.12   <none>        5556:30167/TCP   84m
   

2. Stellen Sie sicher, dass alle Dienste im Verwaltungscluster ausgeführt werden:

   kubectl get pods -A
   

   Es kann einige Minuten dauern, bis der Pinniped-Dienst ausgeführt wird. In AWS- und Azure-Bereitstellungen muss der Dienst beispielsweise warten, bis die IP-Adressen des LoadBalancer bereit sind. Warten Sie, bis pinniped-post-deploy-job abgeschlossen ist, bevor Sie mit den nächsten Schritten fortfahren.

   NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
   [...]
   pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
   

   Hinweis

   Sie können kubectl get pods ausführen, da Sie den admin-Kontext für den Verwaltungscluster verwenden. Benutzer, die versuchen, eine Verbindung mit dem Verwaltungscluster mit dem regulären Kontext herzustellen, können nicht auf dessen Ressourcen zugreifen, da sie noch nicht dazu berechtigt sind.

3. Fahren Sie mit dem Abschnitt Konfigurieren von RBAC für den Verwaltungscluster fort.

(Nur OIDC) Angeben des Callback-URI für den OIDC-Anbieter

Wenn Sie den Verwaltungscluster für die Verwendung der OIDC-Authentifizierung konfiguriert haben, müssen Sie Ihrem OIDC-Identitätsanbieter den Callback-URI für diesen Verwaltungscluster zur Verfügung stellen. Wenn Sie beispielsweise OIDC verwenden und Ihr IDP Okta ist, führen Sie die folgenden Schritte aus:

1. Melden Sie sich bei Ihrem Okta-Konto an.
2. Navigieren Sie im Hauptmenü zu Anwendungen (Applications).
3. Wählen Sie die Anwendung aus, die Sie für Tanzu Kubernetes Grid erstellt haben.
4. Klicken Sie im Bereich „Allgemeine Einstellungen (General Settings)“ auf Bearbeiten (Edit).

5. Aktualisieren Sie unter „Anmelden (Login)“ die Umleitungs-URIs für die Anmeldung (Login redirect URIs), um die Adresse des Knotens aufzunehmen, in dem der pinniped-supervisor ausgeführt wird:

   • vSphere mit NSX ALB, AWS und Azure: Fügen Sie die externe IP-Adresse und die Portnummer des pinniped-supervisor-Diensts hinzu, die Sie im vorherigen Verfahren notiert haben:

     https://EXTERNAL-IP/callback
     

   • vSphere ohne NSX ALB: Fügen Sie die IP-Adresse, die Sie als API-Endpoint festgelegt haben, und die pinniped-supervisor-Portnummer, die Sie im vorherigen Verfahren notiert haben, hinzu:

     https://API-ENDPOINT-IP:31234/callback
     

     In allen Fällen müssen Sie https und nicht http angeben.

6. Klicken Sie auf Speichern.

Konfigurieren von RBAC für den Verwaltungscluster

Wenn Sie planen, standardmäßige, nicht administrative kubeconfig-Dateien für den Zugriff auf den Verwaltungscluster zu verwenden, konfigurieren Sie nach Abschluss der Konfiguration der Identitätsverwaltung RBAC mithilfe der Anweisungen im Abschnitt Konfigurieren von RBAC für einen Verwaltungscluster.

Aktivieren und Konfigurieren der Identitätsverwaltung in einer vorhandenen Bereitstellung

In diesem Abschnitt wird erläutert, wie Sie die Identitätsverwaltung in einer vorhandenen Bereitstellung aktivieren und konfigurieren können.

Abrufen der Details Ihres Identitätsanbieters

Befolgen Sie die Anweisungen im Abschnitt Abrufen der Details Ihres Identitätsanbieters oben.

Generieren des geheimen Pinniped-Add-on-Schlüssels für den Verwaltungscluster

Mit diesem Verfahren werden das Pinniped-Add-on konfiguriert und die Authentifizierungskomponenten in Ihrem Verwaltungscluster bereitgestellt. So generieren Sie einen geheimen Kubernetes-Schlüssel für das Pinniped-Add-on:

1. Legen Sie den Kontext von kubectl auf Ihren Verwaltungscluster fest. Beispielsweise mit einem Verwaltungscluster mit dem Namen id-mgmt-test:

   kubectl config use-context id-mgmt-test-admin@id-mgmt-test
   

2. Erstellen Sie eine Clusterkonfigurationsdatei, indem Sie die Konfigurationseinstellungen, die Sie bei der Bereitstellung Ihres Verwaltungsclusters definiert haben, in eine neue Datei kopieren. Fügen Sie der Konfigurationsdatei des Verwaltungsclusters die folgenden Einstellungen hinzu, einschließlich der Details zum OIDC- oder LDAP-Identitätsanbieter:

   Hinweis

   Sie müssen diese Variablen nur für Verwaltungscluster festlegen.

   # Identity management type. This must be "oidc" or "ldap".
   
   IDENTITY_MANAGEMENT_TYPE:
   
   # Explicitly set the namespace, which for management clusters is "tkg-system".
   
   NAMESPACE: tkg-system
   
   # Set these variables if you want to configure OIDC.
   
   OIDC_IDENTITY_PROVIDER_CLIENT_ID:
   OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
   OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM:
   OIDC_IDENTITY_PROVIDER_ISSUER_URL:
   OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups"
   OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM:
   
   # Set these variables if you want to configure LDAP.
   
   LDAP_BIND_DN:
   LDAP_BIND_PASSWORD:
   LDAP_GROUP_SEARCH_BASE_DN:
   LDAP_GROUP_SEARCH_FILTER:
   LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE:
   LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
   LDAP_GROUP_SEARCH_USER_ATTRIBUTE: DN
   LDAP_HOST:
   LDAP_ROOT_CA_DATA_B64:
   LDAP_USER_SEARCH_BASE_DN:
   LDAP_USER_SEARCH_EMAIL_ATTRIBUTE: DN
   LDAP_USER_SEARCH_FILTER:
   LDAP_USER_SEARCH_ID_ATTRIBUTE: DN
   LDAP_USER_SEARCH_NAME_ATTRIBUTE:
   LDAP_USER_SEARCH_USERNAME: userPrincipalName
   
   # Set these variables if you want to configure certificate duration
   
   CERT_DURATION: 2160h
   CERT_RENEW_BEFORE: 360h
   

   Um festzustellen, welche dieser Variablen optional sind und ausgelassen werden können, wechseln Sie zu Variablen für die Konfiguration von Identitätsanbietern – OIDC und Variablen für die Konfiguration von Identitätsanbietern – LDAP.

   Wenn sich Ihr Verwaltungscluster hinter einem Proxy befindet, müssen Sie sicherstellen, dass die neue Konfigurationsdatei die Details Ihrer Proxy-Konfiguration enthält:

   TKG_HTTP_PROXY:
   TKG_HTTPS_PROXY:
   TKG_NO_PROXY:
   

   Weitere Informationen zu diesen Variablen finden Sie unter Proxy-Konfiguration.

   vSphere: Ändern Sie die Konfigurationseinstellung VSPHERE_CONTROL_PLANE_ENDPOINT als Dummy-Wert zum Bestehen interner Prüfungen in eine nicht verwendete IP-Adresse.

3. Stellen Sie sicher, dass in Ihrer lokalen Umgebung IDENTITY_MANAGEMENT_TYPE entweder auf oidc oder ldap und nicht auf none gesetzt wurde:

   echo $IDENTITY_MANAGEMENT_TYPE
   

   Wenn diese Variable auf none festgelegt ist, führen Sie einen export-Befehl aus, um sie wieder auf oidc oder ldap festzulegen.

4. Legen Sie die Umgebungsvariable _TKG_CLUSTER_FORCE_ROLE auf management fest:

   export _TKG_CLUSTER_FORCE_ROLE="management"
   

   Verwenden Sie unter Windows den Befehl SET.

5. Legen Sie die Umgebungsvariable FILTER_BY_ADDON_TYPE auf authentication/pinniped fest, damit tanzu cluster create nur für Objekte im Zusammenhang mit Pinniped funktioniert:

   export FILTER_BY_ADDON_TYPE="authentication/pinniped"
   

6. Generieren Sie einen geheimen Schlüssel für das Pinniped-Add-on:

   tanzu cluster create CLUSTER-NAME --dry-run -f CLUSTER-CONFIG-FILE > CLUSTER-NAME-example-secret.yaml
   

   Dabei gilt:

   • CLUSTER-NAME ist der Name Ihres Zielverwaltungsclusters.
   • CLUSTER-CONFIG-FILE ist die oben erstellte Konfigurationsdatei.

   Die Einstellungen der Umgebungsvariablen führen dazu, dass tanzu cluster create --dry-run einen geheimen Kubernetes-Schlüssel und kein vollständiges Cluster-Manifest generiert.

7. Überprüfen Sie den geheimen Schlüssel und wenden Sie ihn dann auf den Verwaltungscluster an. Beispiel:

   kubectl apply -f CLUSTER-NAME-example-secret.yaml
   

8. Überprüfen Sie nach dem Anwenden des geheimen Schlüssels den Status des Pinniped-Add-ons, indem Sie den Befehl kubectl get app ausführen:

   $ kubectl get app pinniped -n tkg-system
   NAME           DESCRIPTION             SINCE-DEPLOY    AGE
   pinniped       Reconcile succeeded     3m23s           7h50m
   

   Wenn der zurückgegebene Status Reconcile failed lautet, führen Sie den folgenden Befehl aus, um Details zu dem Fehler abzurufen:

   kubectl get app pinniped -n tkg-system -o yaml
   

Abschließen der Konfiguration der Identitätsverwaltung

Befolgen Sie oben die Anweisungen unter Abschließen der Konfiguration der Identitätsverwaltung.

Aktivieren der Identitätsverwaltung auf Arbeitslastclustern

Alle Arbeitslastcluster, die Sie erstellen, wenn Sie die Identitätsverwaltung im Verwaltungscluster aktivieren, werden automatisch so konfiguriert, dass sie denselben Identitätsverwaltungsdienst verwenden.

Authentifizieren von Benutzern auf einem Computer ohne Browser

Wenn es sich bei Ihrer Bootstrap-Maschine um eine Jumpbox oder einen anderen Computer ohne Display handelt, können Sie sich über einen Browser, der auf Ihrem lokalen Computer ausgeführt wird, bei einem Cluster authentifizieren. Wie Sie dabei vorgehen, hängt von der Pinniped-Version des Clusters ab, die aus dem Tanzu Kubernetes-Release stammt, auf dem der Cluster basiert:

Cluster-TKr-Version	Authentifizierungsvorgang ohne Browser
TKr v1.23.10 (standardmäßig für Tanzu Kubernetes Grid v1.6.1) oder höher	Befolgen Sie die nachstehenden Anweisungen.
Cluster, die auf älteren TKrs basieren oder von älteren Versionen von Tanzu Kubernetes Grid erstellt wurden	Führen Sie das Verfahren unter Authentifizieren von Benutzern auf einem Computer ohne Browser in der Dokumentation zu Tanzu Kubernetes Grid v1.4 aus.

Hinweis

Tanzu Kubernetes Grid v2.1 unterstützt keine browserlose CLI-Anmeldung basierend auf nicht interaktiven Konten oder Kennworterteilungen.

1. Führen Sie in einem Terminalfenster auf Ihrem lokalen Computer ssh aus, um sich remote bei Ihrer Bootstrap-Maschine anzumelden.

2. Legen Sie die Umgebungsvariable TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true fest. Dadurch wird die Option --skip-browser zu kubeconfig für den Cluster hinzugefügt.

   # Linux
   export TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
   # Windows
   set TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
   

3. Exportieren Sie die Standard-kubeconfig für den Cluster in eine lokale Datei. Beachten Sie, dass der Befehl die Option --admin nicht enthält. Daher handelt es sich bei der exportierten kubeconfig um die Standard-kubeconfig und nicht um die admin-Version. So können Sie beispielsweise die kubeconfig-Datei in /tmp/my-cluster-kubeconfig exportieren:

   • Führen Sie für einen Verwaltungscluster Folgendes aus:

     tanzu mc kubeconfig get --export-file /tmp/my-cluster-kubeconfig
     

     Ihnen sollte die folgende Bestätigungsmeldung angezeigt werden: You can now access the cluster by specifying '--kubeconfig /tmp/my-mgmt-cluster-kubeconfig' flag when using 'kubectl' command.

   • Führen Sie für einen Arbeitslastcluster Folgendes aus:

     tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig
     

4. Stellen Sie mithilfe der neu erstellten kubeconfig-Datei eine Verbindung zum Cluster her:

   kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig
   

   Die CLI gibt einen Anmeldelink für Ihren Identitätsanbieter aus. Beispiel:

   Log in by visiting this link:
   
      https://10.180.105.166:31234/oauth2/authorize?access_type=offline&client_id=pinniped-cli&code_challenge=-aJ617vJZXZeEnHPab1V2_VHPmc5VwspFig5QQKyTwg&code_challenge_method=S256&nonce=cafaf8f4d2cb714ef8fb3320c1b088ba&redirect_uri=http%3A%2F%2F127.0.0.1%3A33087%2Fcallback&response_mode=form_post&response_type=code&scope=offline_access+openid+pinniped%3Arequest-audience&state=fff3d4d46b36359d5ba2f24fad471dd8
   
      Optionally, paste your authorization code:
   

5. Kopieren Sie den Link und fügen Sie ihn in einen Browser auf Ihrem lokalen Computer ein.

6. Melden Sie sich im Browser bei Ihrem Identitätsanbieter an. Es wird eine Seite angezeigt, auf der Sie aufgefordert werden, einen Autorisierungscode in die CLI einzufügen:

   

7. Kopieren Sie den Autorisierungscode und fügen Sie ihn in die CLI ein, nachdem Sie die Eingabeaufforderung Optionally, paste your authorization code: erhalten haben.

8. Stellen Sie mithilfe derselben kubeconfig-Datei, die Sie zuvor verwendet haben, erneut eine Verbindung zum Cluster her:

   kubectl get pods -A --kubeconfig FILE-PATH
   

   • Wenn Sie bereits eine Rollenbindung im Cluster für den authentifizierten Benutzer konfiguriert haben, werden in der Ausgabe die Pod-Informationen angezeigt.

   • Wenn Sie keine Rollenbindung im Cluster konfiguriert haben, wird eine Meldung angezeigt, die besagt, dass dem Benutzerkonto der Zugriff auf die Pods verweigert wird: Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" at the cluster scope. Dies geschieht, weil der Benutzer erfolgreich authentifiziert wurde, aber noch nicht berechtigt ist, auf Ressourcen im Cluster zuzugreifen. Um den Benutzer für den Zugriff auf die Clusterressourcen zu autorisieren, müssen Sie RBAC im Cluster konfigurieren, indem Sie eine Clusterrollenbindung erstellen:

     • Weitere Informationen finden Sie unter Erstellen einer Rollenbindung im Verwaltungscluster.
     • Weitere Informationen finden Sie unter Erstellen einer Rollenbindung im Arbeitslastcluster.

Aktualisieren der Dex-Einstellungen nach der Bereitstellung des Verwaltungsclusters

Die Pinniped-Komponente verwendet Dex für LDAP-Identitätsanbieter. Für OIDC-Identitätsanbieter wird Dex nicht verwendet.

Wenn Sie eine Einstellung aktualisieren möchten, die mit dex. im Abschnitt values.yaml des geheimen Pinniped-Schlüssels für den Verwaltungscluster beginnt, müssen Sie die folgenden Schritte ausführen:

1. Ermitteln Sie die dex.-Einstellung oder die zu aktualisierenden Einstellungen. Weitere Informationen finden Sie in der Tabelle unter Aktualisieren des Abschnitts values.yaml.
2. Rufen Sie den geheimen Pinniped-Schlüssel für den Verwaltungscluster ab (siehe Beschreibung im Abschnitt Aktualisieren des Abschnitts values.yaml).

3. Aktualisieren Sie im geheimen Pinniped-Schlüssel die dex.-Einstellung oder die Einstellungen, die Sie oben ermittelt haben. Führen Sie dann die folgenden Schritte aus:

   1. Legen Sie die Array-Konfigurationseinstellungen dex.dns.INFRASTRUCTURE-PROVIDER.ipAddresses und dex.config.dns.INFRASTRUCTURE-PROVIDER.dnsNames fest. Die Felder können auf Arrays mit einem einzelnen, nicht leeren Eintrag festgelegt werden, z. B. 0.0.0.0, da sie automatisch aktualisiert werden.
   2. Legen Sie die Konfigurationseinstellung pinniped.upstream_oidc_issuer_url auf eine nicht leere Zeichenfolge fest, die mit https beginnt. Beispiel: https://0.0.0.0. Dieses Feld wird später automatisch aktualisiert.
   3. Legen Sie die Array-Konfigurationseinstellung dex.config.staticClients auf einen einzelnen Eintrag fest. Die Einstellung kann eine beliebige Zuordnung mit mindestens den Schlüsseln name, id und secret sein, z. B. {name: "example-name", id: "example-id", secret: "example-secret"}, da sie automatisch aktualisiert wird.

   4. Fügen Sie dem geheimen Pinniped-Schlüssel das folgende Overlay hinzu:

      #@ load("@ytt:overlay", "overlay")
      #@overlay/match by=overlay.subset({"metadata": {"name" : "upstream-oidc-identity-provider"}})
      ---
      metadata:
        annotations:
          #@overlay/remove
          kapp.k14s.io/update-strategy: always-replace
      

4. Wenden Sie den geheimen Pinniped-Schlüssel an.

5. Starten Sie den Namespace tanzu-system-auth im Verwaltungscluster neu, nachdem Sie den geheimen Pinniped-Schlüssel angewendet haben. Um den Namespace neu zu starten, können Sie den Namespace löschen und warten, bis die pinniped App ihn neu erstellt hat. Möglicherweise müssen Sie den pinniped-post-deploy-job Job im pinniped-supervisor Namespace neu starten, nachdem Sie den geheimen Pinniped-Schlüssel angewendet haben. Hierfür können Sie den Job löschen und warten, bis er von der pinniped App neu erstellt wird.

Deaktivieren der Identitätsverwaltung in einer vorhandenen Bereitstellung

So deaktivieren Sie die Identitätsverwaltung in einer vorhandenen Bereitstellung, in der die Identitätsverwaltung aktiviert ist:

1. Legen Sie den Kontext von kubectl auf Ihren Verwaltungscluster fest. Beispielsweise mit einem Verwaltungscluster mit dem Namen id-mgmt-test:

   kubectl config use-context id-mgmt-test-admin@id-mgmt-test
   

2. Rufen Sie die Konfigurationsdatei des Verwaltungsclusters ab und bearbeiten Sie sie, um IDENTITY_MANAGEMENT_TYPE: none festzulegen.

3. Generieren Sie eine Pinniped-Secret-Definition, indem Sie tanzu management-cluster create mit --dry-run ausführen und nach Objekten im Zusammenhang mit Pinniped filtern.

   FILTER_BY_ADDON_TYPE=authentication/pinniped tanzu management-cluster create --dry-run CLUSTER-CONFIG > PINNIPED-SECRET
   

   Dabei ist CLUSTER-CONFIG die Clusterkonfigurationsdatei und PINNIPED-SECRET die Definition des generierten geheimen Pinniped-Schlüssels (Secret), wie z. B. mc-no-idp.yaml.

4. Wenden Sie den neuen geheimen Schlüssel an, um Pinniped auf dem Verwaltungscluster zu deaktivieren:

   kubectl apply -f PINNIPED-SECRET
   

5. Nachdem Sie Pinniped auf dem Verwaltungscluster deaktiviert haben, werden seine klassenbasierten Cluster automatisch deaktiviert. Sie müssen jedoch die zugehörigen Legacy-Cluster manuell deaktivieren:

   1. Listet alle geheimen Pinniped-Schlüssel auf, die im Kontext des Verwaltungsclusters verbleiben:

      kubectl get secret -A | grep pinniped-addon
      

   2. Untersuchen Sie die geheimen Schlüssel in der kubectl get secret-Ausgabe, sofern vorhanden, mit dem aufgelisteten geheimen Namen und Namespace:

      kubectl get secret SECRET-NAME -n SECRET-NAMESPACE -o yaml
      

   3. Löschen Sie geheime Schlüssel, die eines der folgenden Elemente enthalten:

      • type: tkg.tanzu.vmware.com/addon – dies sind geheime Schlüssel für Legacy-Cluster
      • beliebige OIDC- oder LDAP-Konfigurationen

      kubectl delete secret SECRET-NAME
      

      Dabei ist SECRET-NAME der Wert von metadata.name, der in der Secret-Spezifikation festgelegt wurde.

Nächste Schritte

Wenn Sie beabsichtigen, standardmäßige, nicht administrative kubeconfig-Dateien zu verwenden, um Benutzern Zugriff auf Ihre Verwaltungs- und Arbeitslastcluster zu gewähren, müssen Sie die RBAC-Autorisierung konfigurieren:

• Um RBAC für den Verwaltungscluster zu konfigurieren, befolgen Sie die Anweisungen unter Konfigurieren von RBAC für einen Verwaltungscluster.
• Nachdem Sie die Schritte in diesem Thema ausgeführt haben, können Sie mit der Erstellung von Arbeitslastclustern beginnen. Um RBAC für die Arbeitslastcluster zu konfigurieren, befolgen Sie die Anweisungen unter Konfigurieren von RBAC für einen Arbeitslastcluster.