Configurer et gérer des certificats TLS pour Pinniped et Dex

Cette rubrique explique comment configurer des certificats TLS personnalisés pour Pinniped et Dex dans Tanzu Kubernetes Grid. Elle explique également comment mettre à jour les certificats Dex dans Tanzu Kubernetes Grid.

Configuration de certificats TLS personnalisés

Par défaut, Tanzu Kubernetes Grid utilise un Issuer auto-signé pour générer les certificats TLS qui sécurisent le trafic HTTPS vers Pinniped et Dex. Vous pouvez mettre à jour la configuration par défaut après le déploiement du cluster de gestion, comme suit :

1. Définissez une ressource ClusterIssuer ou votre propre secret TLS. Reportez-vous à la section Configurer une ressource ClusterIssuer sur un secret TLS ci-dessous.
2. Mettez à jour votre configuration Pinniped en redéployant le secret du module complémentaire Pinniped pour le cluster de gestion. Reportez-vous à la section Mettre à jour votre configuration Pinniped ci-dessous.

Remarque

Tanzu Kubernetes Grid déploie Dex uniquement pour les fournisseurs d'identité LDAP. Si vous configurez un fournisseur d'identité OIDC lorsque vous créez le cluster de gestion ou que vous le configurez en tant qu'étape de post-création, Dex n'est pas déployé.

Définir une ressource ClusterIssuer ou un secret TLS

Si vous souhaitez utiliser une ressource ClusterIssuer pour générer les certificats TLS :

1. Vérifiez que cert-manager est en cours d'exécution dans votre cluster de gestion. Ce composant s'exécute par défaut dans tous les clusters de gestion.
2. Obtenez le nom d'une ressource ClusterIssuer existante dans le cluster de gestion. Pour plus d'informations, reportez-vous à la section Issuer Configuration dans la documentation cert-manager.
3. Spécifiez le nom ClusterIssuer dans le champ custom_cluster_issuer de la section values.yaml du secret du module complémentaire Pinniped pour le cluster de gestion, puis appliquez vos modifications. Pour obtenir des instructions, reportez-vous à la section Mettre à jour votre configuration Pinniped ci-dessous. Une fois les étapes de cette section terminées, les chaînes de certificats Pinniped et Dex seront signées par votre ClusterIssuer.

Si vous souhaitez spécifier directement votre propre secret TLS :

1. Récupérez l'adresse IP ou le nom d'hôte DNS du service Pinniped, pinniped-supervisor et, si vous utilisez un fournisseur d'identité LDAP, du service Dex, dexsvc :

   • Service pinniped-supervisor :

     • Si le type du service est défini sur LoadBalancer (vSphere avec un équilibrage de charge, par exemple, NSX Advanced Load Balancer, Amazon Web Services (AWS) ou Azure), récupérez l'adresse externe du service en exécutant :

       kubectl get service pinniped-supervisor -n pinniped-supervisor
       

     • Si le type du service est défini sur NodePort (vSphere sans équilibrage de charge), l'adresse IP du service est identique à celle du point de terminaison du plan de contrôle vSphere. Pour récupérer l'adresse IP, vous pouvez exécuter la commande suivante :

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

   • (LDAP uniquement) Service dexsvc :

     • Si le type du service est défini sur LoadBalancer (vSphere avec un équilibrage de charge, par exemple, NSX Advanced Load Balancer, Amazon Web Services (AWS) ou Azure), récupérez l'adresse externe du service en exécutant :

       kubectl get service dexsvc -n tanzu-system-auth
       

     • Si le type du service est défini sur NodePort (vSphere sans équilibrage de charge), l'adresse IP du service est identique à celle du point de terminaison du plan de contrôle vSphere. Pour récupérer l'adresse IP, vous pouvez exécuter la commande suivante :

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

2. Créez un secret kubernetes.io/tls dans l'espace de noms pinniped-supervisor si vous utilisez un fournisseur d'identité OIDC. Si vous utilisez un fournisseur d'identité LDAP, créez deux secrets kubernetes.io/tls portant le même nom, l'un, pour le service Pinniped, dans l'espace de noms pinniped-supervisor et l'autre, pour le service Dex, dans l'espace de noms tanzu-system-auth. Pour créer un secret TLS, exécutez :

   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
   

   Remplacez le texte de l'espace réservé comme suit :

   • SECRET-NAME est le nom que vous choisissez pour le secret. Par exemple, my-secret.
   • SECRET-NAMESPACE est l'espace de noms dans lequel créer le secret. Il doit s'agir de pinniped-supervisor pour Pinniped et tanzu-system-auth pour Dex.
   • FILENAME-* est le nom de votre tls.crt, tls.key ou ca.crt. Le certificat TLS que vous spécifiez dans le secret TLS pour Pinniped doit inclure l'adresse IP ou le nom d'hôte DNS du service Pinniped à l'étape ci-dessus. De même, le certificat TLS pour Dex doit inclure l'adresse IP ou le nom d'hôte DNS du service Dex que vous avez récupéré ci-dessus. Le champ ca.crt est requis et contient le bundle d'autorité de certification utilisé pour vérifier le certificat TLS.

   Par exemple, le secret obtenu pour Pinniped ressemble à ceci :

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

   Si le secret a été généré correctement, le décodage tls.crt avec openssl x509 -in tls.crt -text affiche l'adresse IP ou le nom d'hôte DNS dans le champ Autre nom de l'objet (Subject Alternative Name).

3. Spécifiez le nom secret dans le champ custom_tls_secret de la section values.yaml du secret du module complémentaire Pinniped pour le cluster de gestion, puis appliquez vos modifications. Pour obtenir des instructions, reportez-vous à la section Mettre à jour votre configuration Pinniped ci-dessous.

4. Pour configurer un nom d'hôte DNS pour le service Pinniped, spécifiez le nom de domaine complet associé à un superviseur Pinniped dans le champ pinniped.supervisor_svc_external_dns de la section values.yaml du secret du module complémentaire Pinniped pour le cluster de gestion. Notez que la valeur de pinniped.supervisor_svc_external_dns doit commencer par https://. Reportez-vous à la section Paramètres values.yaml des modules autogérés en détail. Ensuite, appliquez vos modifications. Pour obtenir des instructions, reportez-vous à la section Mettre à jour votre configuration Pinniped ci-dessous. Notez que vous devez configurer séparément le DNS pour ce nom d'hôte, par exemple en créant un enregistrement A dans votre fournisseur DNS pour résoudre l'adresse IP du service de superviseur Pinniped. Ce nom d'hôte doit être répertorié comme nom alternatif du sujet dans le certificat TLS que vous configurez pour le superviseur Pinniped.

Mettre à jour la configuration Pinniped

Pour appliquer vos modifications, mettez à jour la configuration Pinniped en suivant les étapes ci-dessous :

1. Enregistrez le secret du module complémentaire Pinniped pour le cluster de gestion dans un fichier et décodez la chaîne codée en Base64 dans la section values.yaml du secret.

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

   Remplacez le texte de l'espace réservé comme suit :

   • CLUSTER-NAME est le nom de votre cluster de gestion.
   • FILENAME est le nom de fichier que vous souhaitez utiliser pour le secret. Par exemple, values.yaml.

2. Dans le texte décodé, effectuez l'une des opérations suivantes :

   • Si vous avez préparé une ressource ClusterIssuer ci-dessus, spécifiez le nom de la ressource dans le champ custom_cluster_issuer. Par exemple :

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

   • Si vous avez préparé votre propre secret TLS ci-dessus, spécifiez son nom dans le champ custom_tls_secret. Par exemple :

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

     Si vous configurez le champ custom_tls_secret, le champ custom_cluster_issuer est ignoré.

     Pour configurer un nom d'hôte DNS pour le service Pinniped, spécifiez le nom de domaine complet qui doit être utilisé pour le superviseur Pinniped dans le champ pinniped.supervisor_svc_external_dns. Par exemple,

     ...
     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. Codez à nouveau la section values.yaml et mettez à jour le secret du module complémentaire Pinniped. Cette commande diffère selon le système d'exploitation de votre environnement. Par exemple :

   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. Vérifiez que les modifications ont bien été appliquées :

   1. Obtenez l'état de l'application pinniped :

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

      Si l'état renvoyé est Échec du rapprochement (Reconcile failed), exécutez la commande suivante pour obtenir des détails sur l'échec :

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

   2. Générez un fichier kubeconfig pour le cluster de gestion en exécutant la commande tanzu mc kubeconfig get --export-file ./KUBECONFIG-MC-CLUSTER-NAME. Exécutez ensuite une commande telle que kubectl get pods --kubeconfig ./KUBECONFIG-MC-CLUSTER-NAME à l'aide de kubeconfig. En outre, si votre cluster de gestion gère des clusters de charge de travail, exécutez tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --export-file ./KUBECONFIG-WORKLOAD-CLUSTER-NAME puis kubectl get pods --kubeconfig ./KUBECONFIG-WORKLOAD-CLUSTER-NAME sur chacun des clusters existants.

Mettre à jour le certificat de service Dex et le certificat d'autorité de certification Dex

Avec les clusters qui utilisent la gestion des identités LDAP, vous souhaiterez peut-être mettre à jour les certificats Dex si :

• Le certificat d'autorité de certification Dex a été mis à jour ou a expiré.
• La clé privée associée à l'autorité de certification Dex est compromise.

Conditions requises

Avant d'effectuer cette procédure, assurez-vous que vous avez :

• Configuré le module complémentaire Pinniped avec le fournisseur d'identité LDAP. Pour plus d'informations, reportez-vous à la section Fournisseurs d'identité – LDAP.
• Obtenu l'adresse du service Dex à l'aide de la commande kubectl get service dexsvc -n tanzu-system-auth.

Mettre à jour le certificat de service Dex

1. Modifiez le contexte kubectl sur le cluster de gestion, si vous vous trouvez actuellement dans le contexte du cluster de charge de travail. Pour plus d'informations, reportez-vous à la section Récupérer le cluster de charge de travail kubeconfig.

2. Téléchargez le certificat de service Dex actuel :

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

   Où :

   • ADDRESS est l'adresse du service Dex dans Tanzu Kubernetes Grid.
   • OLD-FILE est le nom dans lequel vous souhaitez enregistrer le fichier texte du certificat de service, par exemple, before.txt.

3. Supprimez le secret du certificat de service Dex actuel afin que cert-manager le recrée :

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

   Voici un exemple de sortie :

   secret "dex-cert-tls" deleted
   

4. Vérifiez qu'un nouveau certificat de service Dex est créé :

   kubectl get secret -n tanzu-system-auth
   

   Voici un exemple de sortie :

   $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. Redémarrez les espaces Dex :

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

   Voici un exemple de sortie :

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

6. Téléchargez le nouveau certificat de service Dex :

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

   Où :

   • ADDRESS est l'adresse du service Dex dans Tanzu Kubernetes Grid.
   • NEW-FILE est le nom dans lequel vous souhaitez enregistrer le nouveau fichier texte de certificat de service, par exemple, after.txt.

7. Comparez l'ancien et le nouveau certificat pour vous assurer que le nouveau certificat a été créé :

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

   Où :

   • OLD-FILE est le nom de l'ancien certificat de service Dex.
   • NEW-FILE est le nom du nouveau certificat de service Dex.

Mettre à jour le certificat d'autorité de certification Dex

1. Téléchargez le certificat d'autorité de certification Dex actuel :

   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
   

   Où OLD-FILE est le nom dans lequel vous souhaitez enregistrer le fichier texte du certificat de service, par exemple, ca-before.txt.

2. Téléchargez le certificat de service Dex actuel :

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

   Où :

   • ADDRESS est l'adresse du service Dex dans Tanzu Kubernetes Grid.

   • OLD-FILE est le nom dans lequel vous souhaitez enregistrer le fichier texte du certificat de service, par exemple, cert-before.txt.

3. Téléchargez les données de l'autorité de certification Dex actuelle :

   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
   

   Où OLD-FILE est le nom dans lequel vous souhaitez enregistrer le fichier texte du certificat de service, par exemple, ca-data-before.txt.

4. Supprimez le secret du certificat d'autorité de certification Dex afin que cert-manager le recrée :

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

   Voici un exemple de sortie :

   secret "dex-ca-key-pair" deleted
   

5. Vérifiez qu'un nouveau certificat d'autorité de certification Dex est créé :

   kubectl get secret -n tanzu-system-auth
   

   Voici un exemple de sortie :

   $ 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. Supprimez le secret du certificat de service Dex actuel afin que cert-manager le recrée :

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

   Voici un exemple de sortie :

   secret "dex-cert-tls" deleted
   

7. Vérifiez qu'un nouveau certificat de service Dex est créé :

   kubectl get secret -n tanzu-system-auth
   

   Voici un exemple de sortie :

   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. Supprimez la tâche de post-déploiement Pinniped :

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

   Voici un exemple de sortie :

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

9. Mettez à jour le module complémentaire Pinniped pour synchroniser rapidement vos modifications et attendez quelques minutes que le module complémentaire rapproche les modifications :

   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. Téléchargez le nouveau certificat d'autorité de certification 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
    

    Où NEW-FILE est le nom dans lequel vous souhaitez enregistrer le nouveau fichier texte de certificat d'autorité de certification Dex, par exemple, ca-after.txt.

11. Téléchargez le nouveau certificat de service Dex :

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

    Où :

    • ADDRESS est l'adresse du service Dex dans Tanzu Kubernetes Grid.

    • NEW-FILE est le nom dans lequel vous souhaitez enregistrer le nouveau fichier texte du certificat de service Dex, par exemple, after.txt.

    • Téléchargez les nouvelles données de l'autorité de certification 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
    

    Où NEW-FILE est le nom dans lequel vous souhaitez enregistrer le nouveau fichier texte de données d'autorité de certification Dex, par exemple, ca-data-after.txt.

12. Comparez les anciens et les nouveaux certificats d'autorité de certification pour vous assurer que le nouveau certificat d'autorité de certification a été créé :

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

    Où :

    • OLD-FILE est le nom de l'ancien certificat d'autorité de certification Dex.
    • NEW-FILE est le nom de l'ancien certificat d'autorité de certification Dex.

13. Comparez l'ancien et le nouveau certificat de service pour vous assurer que le nouveau certificat de service a été créé :

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

    Où :

    • OLD-FILE est le nom de l'ancien certificat de service Dex.
    • NEW-FILE est le nom de l'ancien certificat de service Dex.

14. Comparez les anciennes et les nouvelles données d'autorité de certification pour vous assurer que les nouvelles données d'autorité de certification ont été créées :

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

    Où :

    • OLD-FILE est le nom de l'ancien fichier de données de l'autorité de certification Dex.
    • NEW-FILE est le nom de l'ancien fichier de données de l'autorité de certification Dex.