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.
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:
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.HinweisTanzu 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.
ClusterIssuer
-Ressource oder eines geheimen TLS-SchlüsselsWenn Sie eine benutzerdefinierte ClusterIssuer
-Ressource zum Generieren der TLS-Zertifikate verwenden möchten:
cert-manager
in Ihrem Verwaltungscluster ausgeführt wird. Diese Komponente wird standardmäßig in allen Verwaltungsclustern ausgeführt.ClusterIssuer
-Ressource im Verwaltungscluster ab. Weitere Informationen finden Sie in der Dokumentation zu cert-manager unter Issuer Configuration.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:
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
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.
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.
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.
Um Ihre Änderungen zu übernehmen, aktualisieren Sie die Pinniped-Konfiguration, indem Sie die folgenden Schritte ausführen:
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
.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
...
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
Bestätigen Sie, dass die Änderungen erfolgreich angewendet wurden:
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
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.
Bei Clustern, in denen die LDAP-Identitätsverwaltung verwendet wird, können Sie die Dex-Zertifikate aktualisieren, wenn Folgendes zutrifft:
Stellen Sie vor der Durchführung dieses Verfahrens sicher, dass Folgendes ausgeführt wurde:
kubectl get service dexsvc -n tanzu-system-auth
abgerufen.Ä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.
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
.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
Ü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
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
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
.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.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
.
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
.
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
.
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
Ü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
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
Ü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
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
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
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
.
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
.
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.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.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.