Konfigurieren und Verwalten von TLS-Zertifikaten für Pinniped und Dex

In diesem Thema wird erläutert, wie Sie benutzerdefinierte TLS-Zertifikate für Pinniped und Dex in Tanzu Kubernetes Grid konfigurieren können. Außerdem wird erläutert, wie die Dex-Zertifikate in Tanzu Kubernetes Grid aktualisiert werden.

Konfigurieren von benutzerdefinierten TLS-Zertifikaten

Standardmäßig verwendet Tanzu Kubernetes Grid einen selbstsignierten Issuer, um die TLS-Zertifikate zu generieren, die den HTTPS-Datenverkehr zu Pinniped und Dex sichern. Optional können Sie die Standardkonfiguration nach der Bereitstellung des Verwaltungsclusters wie folgt aktualisieren:

1. Legen Sie eine benutzerdefinierte ClusterIssuer-Ressource oder Ihren eigenen geheimen TLS-Schlüssel fest. Weitere Informationen finden Sie nachstehend unter Festlegen einer ClusterIssuer-Ressource oder eines geheimen TLS-Schlüssels.
2. Aktualisieren Sie Ihre Pinniped-Konfiguration, indem Sie den geheimen Pinniped-Add-on-Schlüssel für den Verwaltungscluster erneut bereitstellen. Weitere Informationen finden Sie nachstehend unter Aktualisieren Ihrer Pinniped-Konfiguration.

Hinweis

Tanzu Kubernetes Grid stellt Dex nur für LDAP-Identitätsanbieter bereit. Wenn Sie einen OIDC-Identitätsanbieter beim Erstellen des Verwaltungsclusters oder als Schritt nach der Erstellung konfigurieren, wird Dex nicht bereitgestellt.

Festlegen einer ClusterIssuer-Ressource oder eines geheimen TLS-Schlüssels

Wenn Sie eine benutzerdefinierte ClusterIssuer-Ressource zum Generieren der TLS-Zertifikate verwenden möchten:

1. Stellen Sie sicher, dass cert-manager in Ihrem Verwaltungscluster ausgeführt wird. Diese Komponente wird standardmäßig in allen Verwaltungsclustern ausgeführt.
2. Rufen Sie den Namen einer vorhandenen ClusterIssuer-Ressource im Verwaltungscluster ab. Weitere Informationen finden Sie in der Dokumentation zu cert-manager unter Issuer Configuration.
3. Geben Sie den Namen ClusterIssuer im Feld custom_cluster_issuer des Abschnitts values.yaml im geheimen Pinniped-Add-on-Schlüssel für den Verwaltungscluster an und wenden Sie dann Ihre Änderungen an. Anweisungen finden Sie nachstehend unter Aktualisieren Ihrer Pinniped-Konfiguration. Nachdem Sie die Schritte in diesem Abschnitt ausgeführt haben, werden sowohl die Pinniped- als auch die Dex-Zertifikatskette von Ihrem ClusterIssuer signiert.

Wenn Sie Ihren eigenen geheimen TLS-Schlüssel direkt angeben möchten:

1. Rufen Sie die IP-Adresse oder den DNS-Hostnamen des Pinniped-Diensts pinniped-supervisor ab und wenn Sie einen LDAP-Identitätsanbieter verwenden den des Dex-Diensts dexsvc:

   • Der Dienst pinniped-supervisor:

     • Wenn als Diensttyp LoadBalancer festgelegt ist (vSphere mit einem Lastausgleichsdienst, z. B. NSX Advanced Load Balancer, Amazon Web Services (AWS) oder Azure), rufen Sie die externe Adresse des Diensts ab, indem Sie folgenden Befehl ausführen:

       kubectl get service pinniped-supervisor -n pinniped-supervisor
       

     • Wenn als Diensttyp NodePort (vSphere ohne Lastausgleichsdienst) festgelegt ist, ist die IP-Adresse des Diensts mit dem Endpoint der vSphere-Steuerungsebene identisch. Um die IP-Adresse abzurufen, können Sie den folgenden Befehl ausführen:

       kubectl get configmap cluster-info -n kube-public -o yaml
       

   • (Nur LDAP) Der Dienst dexsvc:

     • Wenn als Diensttyp LoadBalancer festgelegt ist (vSphere mit einem Lastausgleichsdienst, z. B. NSX Advanced Load Balancer, Amazon Web Services (AWS) oder Azure), rufen Sie die externe Adresse des Diensts ab, indem Sie folgenden Befehl ausführen:

       kubectl get service dexsvc -n tanzu-system-auth
       

     • Wenn als Diensttyp NodePort (vSphere ohne Lastausgleichsdienst) festgelegt ist, ist die IP-Adresse des Diensts mit dem Endpoint der vSphere-Steuerungsebene identisch. Um die IP-Adresse abzurufen, können Sie den folgenden Befehl ausführen:

       kubectl get configmap cluster-info -n kube-public -o yaml
       

2. Erstellen Sie einen geheimen kubernetes.io/tls-Schlüssel im Namespace pinniped-supervisor, wenn Sie einen OIDC-Identitätsanbieter verwenden. Wenn Sie einen LDAP-Identitätsanbieter verwenden, erstellen Sie zwei geheime kubernetes.io/tls-Schlüssel mit demselben Namen: einen für den Pinniped-Dienst im Namespace pinniped-supervisor und einen für den Dex-Dienst im Namespace tanzu-system-auth. Um einen geheimen TLS-Schlüssel zu erstellen, führen Sie folgenden Befehl aus:

   kubectl create secret generic SECRET-NAME -n SECRET-NAMESPACE --type kubernetes.io/tls --from-file tls.crt=FILENAME-1.crt --from-file tls.key=FILENAME-2.pem --from-file ca.crt=FILENAME-3.pem
   

   Ersetzen Sie den Platzhaltertext wie folgt:

   • SECRET-NAME ist der Name, den Sie für den geheimen Schlüssel ausgewählt haben. Beispiel: my-secret.
   • SECRET-NAMESPACE ist der Namespace, in dem der geheime Schlüssel erstellt werden soll. Dies muss pinniped-supervisor für Pinniped und tanzu-system-auth für Dex sein.
   • FILENAME-* ist der Name Ihrer Datei tls.crt, tls.key oder ca.crt. Das TLS-Zertifikat, das Sie im geheimen TLS-Schlüssel für Pinniped angeben, muss den IP- oder DNS-Hostnamen des Pinniped-Diensts aus dem obigen Schritt enthalten. Ebenso muss das TLS-Zertifikat für Dex die IP-Adresse oder den DNS-Hostnamen des Dex-Diensts enthalten, den Sie oben abgerufen haben. Das Feld ca.crt ist erforderlich und enthält das CA-Paket, das zur Verifizierung des TLS-Zertifikats verwendet wird.

   Der resultierende geheime Schlüssel für Pinniped sieht ähnlich dem Folgenden aus:

   apiVersion: v1
   kind: Secret
   metadata:
    name: my-secret
    namespace: pinniped-supervisor
   type: kubernetes.io/tls
   data:
    tls.crt: |       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
    tls.key: |       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
    ca.crt:  |       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
   

   Wenn der geheime Schlüssel ordnungsgemäß generiert wurde, wird beim Entschlüsseln von tls.crt mit openssl x509 -in tls.crt -text die IP-Adresse oder der DNS-Hostname im Feld „Alternativer Antragstellername (Subject Alternative Name)“ angezeigt.

3. Geben Sie den Namen des geheimen Schlüssels im Feld custom_tls_secret des Abschnitts values.yaml im geheimen Pinniped-Add-on-Schlüssel für den Verwaltungscluster an und wenden Sie dann Ihre Änderungen an. Anweisungen finden Sie nachstehend unter Aktualisieren Ihrer Pinniped-Konfiguration.

4. Wenn Sie einen DNS-Hostnamen für den Pinniped-Dienst konfigurieren möchten, geben Sie den mit einem Pinniped-Supervisor verknüpften FQDN im Feld pinniped.supervisor_svc_external_dns des Abschnitts values.yaml im geheimen Pinniped-Add-On-Schlüssel für den Verwaltungscluster an. Beachten Sie, dass der Wert von pinniped.supervisor_svc_external_dns mit https:// beginnen muss. Weitere Informationen finden Sie unter values.yaml-Einstellungen des automatisch verwalteten Pakets. Wenden Sie dann Ihre Änderungen an. Anweisungen finden Sie nachstehend unter Aktualisieren Ihrer Pinniped-Konfiguration. Beachten Sie, dass Sie DNS für diesen Hostnamen separat konfigurieren müssen, indem Sie beispielsweise einen A-Datensatz in Ihrem DNS-Anbieter erstellen, der in die IP-Adresse des Pinniped-Supervisor-Diensts aufgelöst werden soll. Dieser Hostname muss als alternativer Antragstellername im TLS-Zertifikat aufgeführt sein, das Sie für den Pinniped-Supervisor konfigurieren.

Aktualisieren Ihrer Pinniped-Konfiguration

Um Ihre Änderungen zu übernehmen, aktualisieren Sie die Pinniped-Konfiguration, indem Sie die folgenden Schritte ausführen:

1. Speichern Sie den geheimen Pinniped-Add-On-Schlüssel für den Verwaltungscluster in einer Datei und entschlüsseln Sie die Base64-codierte Zeichenfolge im Abschnitt values.yaml des geheimen Schlüssels.

   kubectl get secret CLUSTER-NAME-pinniped-package -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 -d > FILENAME.yaml
   

   Ersetzen Sie den Platzhaltertext wie folgt:

   • CLUSTER-NAME ist der Name Ihres Verwaltungsclusters.
   • FILENAME ist der Dateiname, den Sie für den geheimen Schlüssel verwenden möchten. Beispiel: values.yaml.

2. Führen Sie im entschlüsselten Text eine der folgenden Aktionen aus:

   • Wenn Sie oben eine ClusterIssuer-Ressource vorbereitet haben, geben Sie den Namen der Ressource im Feld custom_cluster_issuer an. Beispiel:

     ---
     infrastructure_provider: vsphere
     tkg_cluster_role: management
     custom_cluster_issuer: "my-cluster-issuer-name"
     pinniped:
      cert_duration: 2160h
      cert_renew_before: 360h
      supervisor_svc_endpoint: https://10.168.217.220:31234
      supervisor_ca_bundle_data: LS0tLS1CRUdJTiBDRVJUSUZJQ0F……
     ...
     

   • Wenn Sie oben Ihren eigenen TLS-Schlüssel vorbereitet haben, geben Sie den Namen des geheimen Schlüssels im Feld custom_tls_secret an. Beispiel:

     ---
     infrastructure_provider: vsphere
     tkg_cluster_role: management
     custom_tls_secret: "my-tls-secret-name"
     pinniped:
      cert_duration: 2160h
      cert_renew_before: 360h
      supervisor_svc_endpoint: https://10.168.217.220:31234
      supervisor_ca_bundle_data: LS0tLS1CRUdJTiBDRVJUSUZJQ0F……
     ...
     

     Wenn Sie das Feld custom_tls_secret konfigurieren, wird das Feld custom_cluster_issuer ignoriert.

     Wenn Sie einen DNS-Hostnamen für den Pinniped-Dienst konfigurieren möchten, geben Sie im Feld pinniped.supervisor_svc_external_dns den FQDN an, der für den Pinniped-Supervisor verwendet werden soll. Beispiel:

     ...
     pinniped:
     cert_duration: 2160h
     cert_renew_before: 360h
     supervisor_svc_endpoint: https://0.0.0.0:31234
     supervisor_ca_bundle_data: ca_bundle_data_of_supervisor_svc
     supervisor_svc_external_ip: 0.0.0.0
     supervisor_svc_external_dns: https://pinniped.example.com
     ...
     

3. Codieren Sie den Abschnitt values.yaml erneut und aktualisieren Sie den geheimen Schlüssel des Pinniped-Add-Ons. Dieser Befehl unterscheidet sich je nach dem in Ihrer Umgebung eingesetzten Betriebssystem. Beispiel:

   Linux:

   kubectl patch secret CLUSTER-NAME-pinniped-package -n tkg-system -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
   

   macOS:

   kubectl patch secret CLUSTER-NAME-pinniped-package -n tkg-system -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
   

4. Bestätigen Sie, dass die Änderungen erfolgreich angewendet wurden:

   1. Rufen Sie den Status der App pinniped ab:

      kubectl get app CLUSTER-NAME-pinniped -n tkg-system
      

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

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

   2. Generieren Sie eine kubeconfig-Datei für den Verwaltungscluster, indem Sie den Befehl tanzu mc kubeconfig get --export-file ./KUBECONFIG-MC-CLUSTER-NAME ausführen. Führen Sie dann einen Befehl wie kubectl get pods --kubeconfig ./KUBECONFIG-MC-CLUSTER-NAME mithilfe der kubeconfig aus. Wenn Ihr Verwaltungscluster weitere Arbeitslastcluster verwaltet, führen Sie außerdem tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --export-file ./KUBECONFIG-WORKLOAD-CLUSTER-NAME und anschließend kubectl get pods --kubeconfig ./KUBECONFIG-WORKLOAD-CLUSTER-NAME für jeden der vorhandenen Cluster aus.

Aktualisieren des Dex-Dienstzertifikats und des Dex-CA-Zertifikats

Bei Clustern, in denen die LDAP-Identitätsverwaltung verwendet wird, können Sie die Dex-Zertifikate aktualisieren, wenn Folgendes zutrifft:

• Das Dex-CA-Zertifikat wurde aktualisiert oder ist abgelaufen.
• Der mit der Dex-Zertifizierungsstelle verknüpfte private Schlüssel ist kompromittiert.

Voraussetzungen

Stellen Sie vor der Durchführung dieses Verfahrens sicher, dass Folgendes ausgeführt wurde:

• Das Pinniped-Add-on wurde mit LDAP IDP konfiguriert. Weitere Informationen finden Sie unter Identitätsanbieter – LDAP.
• Die Adresse des Dex-Diensts wurde mithilfe des Befehls kubectl get service dexsvc -n tanzu-system-auth abgerufen.

Aktualisieren des Dex-Dienstzertifikats

1. Ändern Sie den kubectl-Kontext in den Verwaltungscluster, wenn Sie sich derzeit im Kontext des Arbeitslastclusters befinden. Weitere Informationen finden Sie unter Abrufen von kubeconfig für Arbeitslastcluster.

2. Laden Sie das aktuelle Dex-Dienstzertifikat herunter:

   openssl s_client -connect ADDRESS:PORT -showcerts </dev/null | openssl x509 -noout -text > /tmp/OLD-FILE.txt
   

   Dabei gilt:

   • ADDRESS ist die Dex-Dienstadresse in Tanzu Kubernetes Grid.
   • OLD-FILE ist der Name, unter dem Sie die Textdatei des Dienstzertifikats speichern möchten, z. B. before.txt.

3. Löschen Sie den aktuellen geheimen Schlüssel des Dex-Dienstzertifikats, sodass er von cert-manager neu erstellt wird:

   kubectl delete secret -n tanzu-system-auth  dex-cert-tls
   

   Nachfolgend finden Sie eine Beispielausgabe:

   secret "dex-cert-tls" deleted
   

4. Überprüfen Sie, ob ein neues Dex-Dienstzertifikat erstellt wurde:

   kubectl get secret -n tanzu-system-auth
   

   Nachfolgend finden Sie eine Beispielausgabe:

   $kubectl get secret -n tanzu-system-auth
   NAME                  TYPE                                  DATA   AGE
   default-token-cg8f2   kubernetes.io/service-account-token   3      6m5s
   dex-ca-key-pair       kubernetes.io/tls                     3      5m50s
   dex-cert-tls          kubernetes.io/tls                     3      2s
   dex-token-p96gl       kubernetes.io/service-account-token   3      6m3s
   

5. Starten Sie die Dex-Pods neu:

   kubectl delete pod -n tanzu-system-auth -l app=dex
   

   Nachfolgend finden Sie eine Beispielausgabe:

   $ kubectl delete pod -n tanzu-system-auth -l app=dex
   pod DEX-POD deleted
   

6. Laden Sie das neue Dex-Dienstzertifikat herunter:

   openssl s_client -connect ADDRESS:PORT -showcerts </dev/null  | openssl x509 -noout -text > /tmp/NEW-FILE.txt
   

   Dabei gilt:

   • ADDRESS ist die Dex-Dienstadresse in Tanzu Kubernetes Grid.
   • NEW-FILE ist der Name, unter dem Sie die Textdatei für das neue Dienstzertifikat speichern möchten, z. B. after.txt.

7. Vergleichen Sie das alte und das neue Zertifikat, um sicherzustellen, dass das neue Zertifikat erstellt wurde:

   diff /tmp/OLD-FILE /tmp/NEW-FILE
   

   Dabei gilt:

   • OLD-FILE ist der Name des alten Dex-Dienstzertifikats.
   • NEW-FILE ist der Name des neuen Dex-Dienstzertifikats.

Aktualisieren des Dex-CA-Zertifikats

1. Laden Sie das aktuelle Dex-CA-Zertifikat herunter:

   kubectl get secret -n tanzu-system-auth dex-cert-tls -o jsonpath={.data.ca\\.crt} | base64 -d | openssl x509 -noout -text > /tmp/OLD-FILE.txt
   

   Dabei ist OLD-FILE der Name, unter dem Sie die Textdatei des Dienstzertifikats speichern möchten, z. B. ca-before.txt.

2. Laden Sie das aktuelle Dex-Dienstzertifikat herunter:

   openssl s_client -connect ADDRESS:PORT -showcerts </dev/null | openssl x509 -noout -text > /tmp/OLD-FILE.txt
   

   Dabei gilt:

   • ADDRESS ist die Dex-Dienstadresse in Tanzu Kubernetes Grid.

   • OLD-FILE ist der Name, unter dem Sie die Textdatei des Dienstzertifikats speichern möchten, z. B. cert-before.txt.

3. Laden Sie die aktuellen Dex-CA-Daten herunter:

   kubectl get oidcidentityprovider upstream-oidc-identity-provider -n pinniped-supervisor -o jsonpath={.spec.tls.certificateAuthorityData} | base64 -d  | openssl x509 -noout -text > /tmp/OLD-FILE.txt
   

   Dabei ist OLD-FILE der Name, unter dem Sie die Textdatei des Dienstzertifikats speichern möchten, z. B. ca-data-before.txt.

4. Löschen Sie den geheimen Schlüssel des Dex-CA-Zertifikats, damit cert-manager ihn neu erstellt:

   kubectl delete secret -n tanzu-system-auth dex-ca-key-pair
   

   Nachfolgend finden Sie eine Beispielausgabe:

   secret "dex-ca-key-pair" deleted
   

5. Überprüfen Sie, ob ein neues Dex-CA-Zertifikat erstellt wurde:

   kubectl get secret -n tanzu-system-auth
   

   Nachfolgend finden Sie eine Beispielausgabe:

   $ kubectl get secret -n tanzu-system-auth
   NAME                  TYPE                                  DATA   AGE
   default-token-cg8f2   kubernetes.io/service-account-token   3      25m
   dex-ca-key-pair       kubernetes.io/tls                     3      18s
   dex-cert-tls          kubernetes.io/tls                     3      17s
   dex-token-p96gl       kubernetes.io/service-account-token   3      25m
   
   

6. Löschen Sie den aktuellen geheimen Schlüssel des Dex-Dienstzertifikats, sodass er von cert-manager neu erstellt wird:

   kubectl delete secret -n tanzu-system-auth  dex-cert-tls
   

   Nachfolgend finden Sie eine Beispielausgabe:

   secret "dex-cert-tls" deleted
   

7. Überprüfen Sie, ob ein neues Dex-Dienstzertifikat erstellt wurde:

   kubectl get secret -n tanzu-system-auth
   

   Nachfolgend finden Sie eine Beispielausgabe:

   kubectl get secret -n tanzu-system-auth
   NAME                  TYPE                                  DATA   AGE
   default-token-cg8f2   kubernetes.io/service-account-token   3      6m5s
   dex-ca-key-pair       kubernetes.io/tls                     3      5m50s
   dex-cert-tls          kubernetes.io/tls                     3      2s
   dex-token-p96gl       kubernetes.io/service-account-token   3      6m3s
   

8. Löschen Sie den Pinniped-Auftrag nach der Bereitstellung:

   kubectl delete job -n pinniped-supervisor pinniped-post-deploy-job
   

   Nachfolgend finden Sie eine Beispielausgabe:

   job.batch "pinniped-post-deploy-job" deleted
   

9. Aktualisieren Sie das Pinniped-Add-on, um Ihre Änderungen schnell zu synchronisieren, und warten Sie einige Minuten, bis das Add-on die Änderungen abgleicht:

   kubectl patch app pinniped -n tkg-system -p '{"spec":{"syncPeriod":"30s"}}' --type merge
   

   kubectl wait app pinniped -n tkg-system --for condition=ReconcileSucceeded --timeout 5m
   

10. Laden Sie das neue Dex-CA-Zertifikat herunter:

    kubectl get secret -n tanzu-system-auth dex-cert-tls -o jsonpath={.data.ca\\.crt} | base64 -d | openssl x509 -noout -text > /tmp/NEW-FILE.txt
    

    Dabei ist NEW-FILE der Name, unter dem Sie die Textdatei des neuen Dex-CA-Zertifikats speichern möchten, z. B. ca-after.txt.

11. Laden Sie das neue Dex-Dienstzertifikat herunter:

    openssl s_client -connect ADDRESS:PORT -showcerts </dev/null  | openssl x509 -noout -text > /tmp/NEW-FILE.txt
    

    Dabei gilt:

    • ADDRESS ist die Dex-Dienstadresse in Tanzu Kubernetes Grid.

    • NEW-FILE ist der Name, unter dem Sie die Textdatei für das neue Dex-Dienstzertifikat speichern möchten, z. B. after.txt.

    • Laden Sie die neuen Dex-CA-Daten herunter:

    kubectl get oidcidentityprovider upstream-oidc-identity-provider -n pinniped-supervisor -o jsonpath={.spec.tls.certificateAuthorityData} | base64 -d  | openssl x509 -noout -text > /tmp/NEW-FILE.txt
    

    Dabei ist NEW-FILE der Name, unter dem Sie die Textdatei mit den neuen Dex-CA-Daten speichern möchten, z. B. ca-data-after.txt.

12. Vergleichen Sie das alte und das neue CA-Zertifikat, um sicherzustellen, dass das neue CA-Zertifikat erstellt wurde:

    diff /tmp/OLD-FILE /tmp/NEW-FILE
    

    Dabei gilt:

    • OLD-FILE ist der Name des alten Dex-CA-Zertifikats.
    • NEW-FILE ist der Name des alten Dex-CA-Zertifikats.

13. Vergleichen Sie das alte und das neue Dienstzertifikat, um sicherzustellen, dass das neue Dienstzertifikat erstellt wurde:

    diff /tmp/OLD-FILE /tmp/NEW-FILE
    

    Dabei gilt:

    • OLD-FILE ist der Name des alten Dex-Dienstzertifikats.
    • NEW-FILE ist der Name des alten Dex-Dienstzertifikats.

14. Vergleichen Sie die alten und die neuen CA-Daten, um sicherzustellen, dass die neuen CA-Daten erstellt wurden:

    diff /tmp/OLD-FILE /tmp/NEW-FILE
    

    Dabei gilt:

    • OLD-FILE ist der Name der alten Dex-CA-Datendatei.
    • NEW-FILE ist der Name der alten Dex-CA-Datendatei.