Configurazione e gestione dei certificati TLS per Pinniped e Dex

Questo argomento spiega come configurare certificati TLS personalizzati per Pinniped e Dex in Tanzu Kubernetes Grid. Spiega inoltre come aggiornare i certificati Dex in Tanzu Kubernetes Grid.

Configurazione di certificati TLS personalizzati

Per impostazione predefinita, Tanzu Kubernetes Grid utilizza un Issuer autofirmato per generare i certificati TLS che proteggono il traffico HTTPS verso Pinniped e Dex. Facoltativamente, è possibile aggiornare la configurazione predefinita dopo la distribuzione del cluster di gestione, come indicato di seguito:

  1. Impostare una risorsa ClusterIssuer personalizzata o un segreto TLS. Vedere Impostazione di una risorsa ClusterIssuer o un segreto TLS di seguito.
  2. Aggiornare la configurazione di Pinniped ridistribuendo il segreto del componente aggiuntivo Pinniped per il cluster di gestione. Vedere Aggiornamento della configurazione di Pinniped di seguito.
Nota

Tanzu Kubernetes Grid distribuisce Dex solo per i provider di identità LDAP. Se si configura un provider di identità OIDC quando si crea il cluster di gestione o lo si configura come passaggio successivo alla creazione, Dex non viene distribuito.

Impostazione di una risorsa ClusterIssuer o un segreto TLS

Se si desidera utilizzare una risorsa ClusterIssuer personalizzata per generare i certificati TLS:

  1. Verificare che cert-manager sia in esecuzione nel cluster di gestione. Questo componente viene eseguito per impostazione predefinita in tutti i cluster di gestione.
  2. Recuperare il nome di una risorsa ClusterIssuer esistente nel cluster di gestione. Per ulteriori informazioni, vedere Configurazione dell'emittente nella documentazione di cert-manager.
  3. Specificare il nome di ClusterIssuer nel campo custom_cluster_issuer della sezione values.yaml nel segreto del componente aggiuntivo Pinniped per il cluster di gestione e quindi applicare le modifiche. Per istruzioni, vedere Aggiornamento della configurazione di Pinniped di seguito. Dopo aver completato i passaggi indicati in questa sezione, entrambe le catene di certificati Pinniped e Dex saranno firmate da ClusterIssuer.

Se si desidera specificare direttamente il proprio segreto TLS:

  1. Recuperare l'indirizzo IP o il nome host DNS del servizio Pinniped, pinniped-supervisor, e se si utilizza un provider di identità LDAP, del servizio Dex, dexsvc:

    • Servizio pinniped-supervisor:

      • Se il tipo di servizio è impostato su LoadBalancer (vSphere con bilanciamento del carico, ad esempio NSX Advanced Load Balancer, Amazon Web Services (AWS) o Azure), recuperare l'indirizzo esterno del servizio eseguendo:

        kubectl get service pinniped-supervisor -n pinniped-supervisor

      • Se il tipo di servizio è impostato su NodePort (vSphere senza bilanciamento del carico), l'indirizzo IP del servizio è uguale all'endpoint del piano di controllo di vSphere. Per recuperare l'indirizzo IP, è possibile eseguire il comando seguente:

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

    • (Solo LDAP) Servizio dexsvc:

      • Se il tipo di servizio è impostato su LoadBalancer (vSphere con bilanciamento del carico, ad esempio NSX Advanced Load Balancer, Amazon Web Services (AWS) o Azure), recuperare l'indirizzo esterno del servizio eseguendo:

        kubectl get service dexsvc -n tanzu-system-auth

      • Se il tipo di servizio è impostato su NodePort (vSphere senza bilanciamento del carico), l'indirizzo IP del servizio è uguale all'endpoint del piano di controllo di vSphere. Per recuperare l'indirizzo IP, è possibile eseguire il comando seguente:

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

  2. Creare un segreto kubernetes.io/tls nello spazio dei nomi pinniped-supervisor se si utilizza un provider di identità OIDC. Se si utilizza un provider di identità LDAP, creare due segreti kubernetes.io/tls con lo stesso nome, uno per il servizio Pinniped nello spazio dei nomi pinniped-supervisor e uno per il servizio Dex nello spazio dei nomi tanzu-system-auth. Per creare un segreto TLS, eseguire:

    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

    Sostituire il testo segnaposto nel modo seguente:

    • SECRET-NAME è il nome scelto per il segreto. Ad esempio my-secret.
    • SECRET-NAMESPACE è lo spazio dei nomi in cui creare il segreto. Deve essere pinniped-supervisor per Pinniped e tanzu-system-auth per Dex.
    • FILENAME-* è il nome di tls.crt, tls.key o ca.crt. Il certificato TLS specificato nel segreto TLS per Pinniped deve includere l'IP o il nome host DNS del servizio Pinniped del passaggio precedente. Analogamente, il certificato TLS per Dex deve includere l'indirizzo IP o il nome host DNS del servizio Dex recuperato in precedenza. Il campo ca.crt è obbligatorio e contiene il bundle CA utilizzato per verificare il certificato TLS.

    Ad esempio, il segreto risultante per Pinniped è simile al seguente:

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

    Se il segreto è stato generato correttamente, quando si decodifica tls.crt con openssl x509 -in tls.crt -text, viene visualizzato l'indirizzo IP o il nome host DNS nel campo Nome alternativo oggetto (Subject Alternative Name).

  3. Specificare il nome del segreto nel campo custom_tls_secret della sezione values.yaml nel segreto del componente aggiuntivo Pinniped per il cluster di gestione e quindi applicare le modifiche. Per istruzioni, vedere Aggiornamento della configurazione di Pinniped di seguito.

  4. Se si desidera configurare un nome host DNS per il servizio Pinniped, specificare l’FQDN associato a un supervisore Pinniped nel campo pinniped.supervisor_svc_external_dns della sezione values.yaml nel segreto del componente aggiuntivo Pinniped per il cluster di gestione. Tenere presente che il valore di pinniped.supervisor_svc_external_dns deve iniziare con https://. Vedere Impostazioni di values.yaml dei pacchetti gestiti automaticamente in dettaglio. Applicare quindi le modifiche. Per istruzioni, vedere Aggiornamento della configurazione di Pinniped di seguito. Tenere presente che è necessario configurare il DNS separatamente per questo nome host, ad esempio creando un record A nel provider DNS per la risoluzione nell'indirizzo IP del servizio del supervisore Pinniped. Questo nome host deve essere elencato come nome alternativo dell'oggetto nel certificato TLS configurato per il supervisore Pinniped.

Aggiornamento della configurazione di Pinniped

Per applicare le modifiche, aggiornare la configurazione di Pinniped eseguendo i passaggi seguenti:

  1. Salvare il segreto del componente aggiuntivo Pinniped per il cluster di gestione in un file e decodificare la stringa con codifica Base64 nella sezione values.yaml del segreto.

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

    Sostituire il testo segnaposto nel modo seguente:

    • CLUSTER-NAME è il nome del cluster di gestione.
    • FILENAME è il nome del file che si desidera utilizzare per il segreto. Ad esempio values.yaml.

  2. Nel testo decodificato eseguire una delle operazioni seguenti:

    • Se in precedenza è stata preparata una risorsa ClusterIssuer, specificare il nome della risorsa nel campo custom_cluster_issuer. Ad esempio:

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

    • Se in precedenza è stato preparato un segreto TLS personalizzato, specificare il nome del segreto nel campo custom_tls_secret. Ad esempio:

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

      Se si configura il campo custom_tls_secret, il campo custom_cluster_issuer viene ignorato.

      Se si desidera configurare un nome host DNS per il servizio Pinniped, specificare l’FQDN da utilizzare per il supervisore Pinniped nel campo pinniped.supervisor_svc_external_dns. Ad esempio,

      ...
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. Codificare nuovamente la sezione values.yaml e aggiornare il segreto del componente aggiuntivo Pinniped. Questo comando varia in base al sistema operativo del proprio ambiente. Ad esempio:

    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. Verificare che le modifiche siano state applicate correttamente:

    1. Recuperare lo stato dell'app pinniped:

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

      Se lo stato restituito è Riconciliazione non riuscita (Reconcile failed), eseguire il comando seguente per recuperare dettagli sull'errore:

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

    2. Generare un file kubeconfig per il cluster di gestione eseguendo il comando tanzu mc kubeconfig get --export-file ./KUBECONFIG-MC-CLUSTER-NAME. Eseguire quindi un comando come kubectl get pods --kubeconfig ./KUBECONFIG-MC-CLUSTER-NAME utilizzando kubeconfig. Inoltre, se il cluster di gestione gestisce cluster del carico di lavoro, eseguire tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --export-file ./KUBECONFIG-WORKLOAD-CLUSTER-NAME e quindi kubectl get pods --kubeconfig ./KUBECONFIG-WORKLOAD-CLUSTER-NAME per ciascuno dei cluster esistenti.

Aggiornamento del certificato del servizio Dex e del certificato CA di Dex

Quando i cluster utilizzano la gestione delle identità LDAP, è possibile aggiornare i certificati Dex se:

  • Il certificato CA di Dex è stato aggiornato o è scaduto.
  • La chiave privata associata all'autorità di certificazione di Dex è compromessa.

Prerequisiti

Prima di eseguire questa procedura, assicurarsi di aver:

  • Configurato il componente aggiuntivo Pinniped con il provider di identità LDAP. Per ulteriori informazioni, vedere Provider di identità - LDAP.
  • Recuperato l'indirizzo del servizio Dex utilizzando il comando kubectl get service dexsvc -n tanzu-system-auth.

Aggiornamento del certificato del servizio Dex

  1. Se al momento ci si trova nel contesto del cluster del carico di lavoro, sostituire il contesto di kubectl impostandolo sul cluster di gestione. Per ulteriori informazioni, vedere Recupero di kubeconfig del cluster del carico di lavoro.

  2. Scaricare il certificato del servizio Dex corrente:

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

    In cui:

    • ADDRESS è l'indirizzo del servizio Dex in Tanzu Kubernetes Grid.
    • OLD-FILE è il nome con cui si desidera salvare il file di testo del certificato del servizio, ad esempio before.txt.

  3. Eliminare il segreto del certificato del servizio Dex corrente in modo che cert-manager lo ricrei:

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

    Un output di esempio è il seguente:

    secret "dex-cert-tls" deleted

  4. Verificare che sia stato creato un nuovo certificato del servizio Dex:

    kubectl get secret -n tanzu-system-auth

    Un output di esempio è il seguente:

    $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. Riavviare i pod di Dex:

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

    Un output di esempio è il seguente:

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

  6. Scaricare il nuovo certificato del servizio Dex:

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

    In cui:

    • ADDRESS è l'indirizzo del servizio Dex in Tanzu Kubernetes Grid.
    • NEW-FILE è il nome con cui si desidera salvare il nuovo file di testo del certificato del servizio, ad esempio after.txt.

  7. Confrontare il vecchio e il nuovo certificato per assicurarsi che il nuovo certificato sia stato creato:

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

    In cui:

    • OLD-FILE è il nome del vecchio certificato del servizio Dex.
    • NEW-FILE è il nome del nuovo certificato del servizio Dex.

Aggiornamento del certificato CA di Dex

  1. Scaricare il certificato CA di Dex corrente:

    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

    In cui OLD-FILE è il nome con cui si desidera salvare il file di testo del certificato del servizio, ad esempio ca-before.txt.

  2. Scaricare il certificato del servizio Dex corrente:

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

    In cui:

    • ADDRESS è l'indirizzo del servizio Dex in Tanzu Kubernetes Grid.

    • OLD-FILE è il nome con cui si desidera salvare il file di testo del certificato del servizio, ad esempio cert-before.txt.

  3. Scaricare i dati del certificato CA di Dex corrente:

    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

    In cui OLD-FILE è il nome con cui si desidera salvare il file di testo del certificato del servizio, ad esempio ca-data-before.txt.

  4. Eliminare il segreto del certificato CA di Dex in modo che cert-manager lo ricrei:

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

    Un output di esempio è il seguente:

    secret "dex-ca-key-pair" deleted

  5. Verificare che sia stato creato un nuovo certificato CA di Dex:

    kubectl get secret -n tanzu-system-auth

    Un output di esempio è il seguente:

    $ 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. Eliminare il segreto del certificato del servizio Dex corrente in modo che cert-manager lo ricrei:

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

    Un output di esempio è il seguente:

    secret "dex-cert-tls" deleted

  7. Verificare che sia stato creato un nuovo certificato del servizio Dex:

    kubectl get secret -n tanzu-system-auth

    Un output di esempio è il seguente:

    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. Eliminare il processo successivo alla distribuzione di Pinniped:

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

    Un output di esempio è il seguente:

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

  9. Aggiornare il componente aggiuntivo Pinniped per sincronizzare rapidamente le modifiche e attendere qualche minuto che il componente aggiuntivo riconcili le modifiche:

    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. Scaricare il nuovo certificato CA di Dex:

    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

    In cui NEW-FILE è il nome con cui si desidera salvare il nuovo file di testo del certificato CA di Dex, ad esempio ca-after.txt.

  11. Scaricare il nuovo certificato del servizio Dex:

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

    In cui:

    • ADDRESS è l'indirizzo del servizio Dex in Tanzu Kubernetes Grid.

    • NEW-FILE è il nome con cui si desidera salvare il nuovo file di testo del certificato del servizio Dex, ad esempio after.txt.

    • Scaricare i dati del nuovo certificato CA di Dex:

    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

    In cui NEW-FILE è il nome con cui si desidera salvare il nuovo file di testo dei dati del certificato CA di Dex, ad esempio ca-data-after.txt.

  12. Confrontare il vecchio e il nuovo certificato per assicurarsi che il nuovo certificato CA sia stato creato:

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

    In cui:

    • OLD-FILE è il nome del vecchio certificato CA di Dex.
    • NEW-FILE è il nome del vecchio certificato CA di Dex.

  13. Confrontare il vecchio e il nuovo certificato del servizio per assicurarsi che il nuovo certificato del servizio sia stato creato:

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

    In cui:

    • OLD-FILE è il nome del vecchio certificato del servizio Dex.
    • NEW-FILE è il nome del vecchio certificato del servizio Dex.

  14. Confrontare i dati del vecchio e del nuovo certificato CA per assicurarsi che i dati del nuovo certificato CA siano stati creati:

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

    In cui:

    • OLD-FILE è il nome del vecchio file di dati CA di Dex.
    • NEW-FILE è il nome del nuovo file di dati CA di Dex.
check-circle-line exclamation-circle-line close-line
Scroll to top icon