Configurar y administrar certificados TLS para Pinniped y Dex

En este tema se explica cómo configurar certificados TLS personalizados para Pinniped y Dex en Tanzu Kubernetes Grid. También se explica cómo actualizar los certificados Dex en Tanzu Kubernetes Grid.

Configurar certificados TLS personalizados

De forma predeterminada, Tanzu Kubernetes Grid utiliza un Issuer autofirmado para generar los certificados TLS que protegen el tráfico HTTPS a Pinniped y Dex. Opcionalmente, puede actualizar la configuración predeterminada después de implementar el clúster de administración de la siguiente manera:

  1. Establezca un recurso ClusterIssuer personalizado o su propio secreto TLS. Consulte Establecer un recurso ClusterIssuer o un secreto TLS a continuación.
  2. Actualice la configuración de Pinniped volviendo a implementar el secreto del complemento pinniped para el clúster de administración. Consulte Actualizar la configuración de Pinniped a continuación.
Nota

Tanzu Kubernetes Grid implementa Dex solo para los proveedores de identidad de LDAP. Si configura un proveedor de identidad de OIDC cuando crea el clúster de administración o lo configura como un paso posterior a la creación, Dex no se implementa.

Establecer un recurso ClusterIssuer o un secreto TLS

Si desea utilizar un recurso ClusterIssuer para generar los certificados TLS:

  1. Compruebe que cert-manager se esté ejecutando en el clúster de administración. Este componente se ejecuta de forma predeterminada en todos los clústeres de administración.
  2. Obtenga el nombre de un recurso ClusterIssuer existente en el clúster de administración. Para obtener más información, consulte Configuración del emisor en la documentación de cert-manager.
  3. Especifique el nombre ClusterIssuer en el campo custom_cluster_issuer de la sección values.yaml del secreto del complemento Pinniped para el clúster de administración y, a continuación, aplique los cambios. Para obtener instrucciones, consulte Actualizar la configuración de Pinniped a continuación. Después de completar los pasos de esta sección, ClusterIssuer firmará ambas cadenas de certificados Pinniped y Dex.

Si desea especificar su propio secreto TLS directamente:

  1. Recupere la dirección IP o el nombre de host de DNS del servicio Pinniped, pinniped-supervisor y, si utiliza un proveedor de identidades LDAP, del servicio de Dex, dexsvc:

    • El servicio pinniped-supervisor:

      • Si el tipo de servicio se establece en LoadBalancer (vSphere con un equilibrador de carga, por ejemplo, NSX Advanced Load Balancer, Amazon Web Services [AWS] o Azure), recupere la dirección externa del servicio ejecutando:

        kubectl get service pinniped-supervisor -n pinniped-supervisor

      • Si el tipo de servicio se establece en NodePort (vSphere sin un equilibrador de carga), la dirección IP del servicio es la misma que el endpoint del plano de control de vSphere. Para recuperar la dirección IP, puede ejecutar el siguiente comando:

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

    • (Solo LDAP) El servicio de dexsvc:

      • Si el tipo de servicio se establece en LoadBalancer (vSphere con un equilibrador de carga, por ejemplo, NSX Advanced Load Balancer, Amazon Web Services [AWS] o Azure), recupere la dirección externa del servicio ejecutando:

        kubectl get service dexsvc -n tanzu-system-auth

      • Si el tipo de servicio se establece en NodePort (vSphere sin un equilibrador de carga), la dirección IP del servicio es la misma que el endpoint del plano de control de vSphere. Para recuperar la dirección IP, puede ejecutar el siguiente comando:

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

  2. Cree un secreto de kubernetes.io/tls en el espacio de nombres pinniped-supervisor si utiliza un proveedor de identidad de OIDC. Si utiliza un proveedor de identidades LDAP, cree dos secretos kubernetes.io/tls con el mismo nombre, uno para el servicio Pinniped en el espacio de nombres pinniped-supervisor y otro para el servicio de Dex en el espacio de nombres tanzu-system-auth. Para crear un secreto TLS, ejecute:

    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

    Reemplace el texto de marcador de posición de la siguiente manera:

    • SECRET-NAME es el nombre que eligió para el secreto. Por ejemplo, my-secret.
    • SECRET-NAMESPACE es el espacio de nombres en el que se crea el secreto. Debe ser pinniped-supervisor para Pinniped y tanzu-system-auth para Dex.
    • FILENAME-* es el nombre de sus tls.crt, tls.key o ca.crt. El certificado TLS que especifique en el secreto de TLS para Pinniped debe incluir la IP o el nombre de host DNS del servicio Pinniped del paso anterior. De forma similar, el certificado TLS para Dex debe incluir la dirección IP o el nombre de host DNS del servicio de Dex que recuperó anteriormente. El campo ca.crt es obligatorio y contiene el paquete de CA que se utiliza para comprobar el certificado TLS.

    Por ejemplo, el secreto resultante para Pinniped tiene un aspecto similar al siguiente:

    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 el secreto se generó correctamente, la descodificación tls.crt con openssl x509 -in tls.crt -text muestra la dirección IP o el nombre de host de DNS en el campo Nombre alternativo del sujeto.

  3. Especifique el nombre del secreto en el campo custom_tls_secret de la sección values.yaml del secreto de complemento Pinniped para el clúster de administración y, a continuación, aplique los cambios. Para obtener instrucciones, consulte Actualizar la configuración de Pinniped a continuación.

  4. Si desea configurar un nombre de host de DNS para el servicio Pinniped, especifique el FQDN asociado con un supervisor Pinniped en el campo pinniped.supervisor_svc_external_dns de la sección values.yaml del secreto del complemento Pinniped del clúster de administración. Tenga en cuenta que el valor de pinniped.supervisor_svc_external_dns debe comenzar con https://. Consulte la configuración de values.yaml del paquete administrado automáticamente en detalle. A continuación, aplique los cambios. Para obtener instrucciones, consulte Actualizar la configuración de Pinniped a continuación. Tenga en cuenta que debe configurar el DNS por separado para este nombre de host; por ejemplo, debe crear un registro A en el proveedor de DNS para resolver la dirección IP del servicio de supervisor Pinniped. Este nombre de host debe aparecer como nombre alternativo del asunto en el certificado TLS que configure para el supervisor Pinniped.

Actualizar la configuración de Pinniped

Para aplicar los cambios, actualice la configuración de Pinniped siguiendo los pasos que se indican a continuación:

  1. Guarde el secreto del complemento Pinniped para el clúster de administración en un archivo y descodifique la cadena con codificación Base64 en la sección values.yaml del secreto.

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

    Reemplace el texto de marcador de posición de la siguiente manera:

    • CLUSTER-NAME es el nombre de su clúster de administración.
    • FILENAME es el nombre de archivo que desea utilizar para el secreto. Por ejemplo, values.yaml.

  2. En el texto decodificado, realice una de las siguientes acciones:

    • Si preparó un recurso ClusterIssuer anterior, especifique el nombre del recurso en el campo custom_cluster_issuer. Por ejemplo:

      ---
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 preparó su propio secreto TLS anteriormente, especifique el nombre del secreto en el campo custom_tls_secret. Por ejemplo:

      ---
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 configura el campo custom_tls_secret, se ignorará el custom_cluster_issuer.

      Si desea configurar un nombre de host de DNS para el servicio Pinniped, especifique el FQDN que se debe utilizar para el supervisor Pinniped en el campo pinniped.supervisor_svc_external_dns. Por ejemplo:

      ...
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. Vuelva a codificar la sección values.yaml y actualice el secreto del complemento Pinniped. Este comando varía según el sistema operativo del entorno. Por ejemplo:

    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. Confirme que los cambios se han aplicado correctamente:

    1. Obtenga el estado de la aplicación pinniped:

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

      Si el estado devuelto es Reconciliación fallida, ejecute el siguiente comando para obtener detalles sobre el fallo:

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

    2. Para generar un archivo kubeconfig para el clúster de administración, ejecute el comando tanzu mc kubeconfig get --export-file ./KUBECONFIG-MC-CLUSTER-NAME. A continuación, ejecute un comando como kubectl get pods --kubeconfig ./KUBECONFIG-MC-CLUSTER-NAME mediante kubeconfig. Además, si el clúster de administración administra algún clúster de carga de trabajo, ejecute tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --export-file ./KUBECONFIG-WORKLOAD-CLUSTER-NAME y, a continuación, kubectl get pods --kubeconfig ./KUBECONFIG-WORKLOAD-CLUSTER-NAME en cada uno de los clústeres existentes.

Actualizar certificado de servicio de Dex y certificado de CA Dex

Con los clústeres que utilizan la administración de identidades LDAP, es posible que desee actualizar los certificados Dex si:

  • El certificado de CA Dex se actualizó o caducó.
  • La clave privada asociada con CA Dex se ve comprometida.

Requisitos previos

Antes de realizar este procedimiento, asegúrese de que dispone de:

  • Se configuró el complemento Pinniped con el IDP de LDAP. Para obtener más información, consulte Proveedores de identidad: LDAP.
  • Se obtuvo la dirección del servicio de Dex mediante el comando kubectl get service dexsvc -n tanzu-system-auth.

Actualizar el certificado de servicio de Dex

  1. Cambie el contexto de kubectl al clúster de administración, si se encuentra actualmente en el contexto del clúster de carga de trabajo. Para obtener más información, consulte Recuperar clúster de carga de trabajo kubeconfig.

  2. Descargue el certificado de servicio de Dex actual:

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

    Donde:

    • ADDRESS es la dirección del servicio de Dex en Tanzu Kubernetes Grid.
    • OLD-FILE es el nombre en el que desea guardar el archivo de texto del certificado de servicio, por ejemplo, before.txt.

  3. Elimine el secreto del certificado de servicio de Dex actual para que cert-manager lo vuelva a crear:

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

    A continuación se muestra un ejemplo de resultados:

    secret "dex-cert-tls" deleted

  4. Compruebe que se haya creado un nuevo certificado de servicio de Dex:

    kubectl get secret -n tanzu-system-auth

    A continuación se muestra un ejemplo de resultados:

    $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. Reinicie los pods de Dex:

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

    A continuación se muestra un ejemplo de resultados:

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

  6. Descargue el nuevo certificado de servicio de Dex:

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

    Donde:

    • ADDRESS es la dirección del servicio de Dex en Tanzu Kubernetes Grid.
    • NEW-FILE es el nombre en el que desea guardar el nuevo archivo de texto del certificado de servicio, por ejemplo, after.txt.

  7. Compare los certificados antiguos y nuevos para asegurarse de que se haya creado el nuevo certificado:

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

    Donde:

    • OLD-FILE es el nombre del certificado de servicio de Dex anterior.
    • NEW-FILE es el nombre del nuevo certificado de servicio de Dex.

Actualice el certificado de CA Dex

  1. Descargue el certificado de CA Dex actual:

    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

    Donde OLD-FILE es el nombre en el que desea guardar el archivo de texto del certificado de servicio, por ejemplo, ca-before.txt.

  2. Descargue el certificado de servicio de Dex actual:

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

    Donde:

    • ADDRESS es la dirección del servicio de Dex en Tanzu Kubernetes Grid.

    • OLD-FILE es el nombre en el que desea guardar el archivo de texto del certificado de servicio, por ejemplo, cert-before.txt.

  3. Descargue los datos actuales de CA Dex:

    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

    Donde OLD-FILE es el nombre en el que desea guardar el archivo de texto del certificado de servicio, por ejemplo, ca-data-before.txt.

  4. Elimine el secreto del certificado de CA Dex para que cert-manager lo vuelva a crear:

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

    A continuación se muestra un ejemplo de resultados:

    secret "dex-ca-key-pair" deleted

  5. Compruebe que se haya creado un nuevo certificado de CA Dex:

    kubectl get secret -n tanzu-system-auth

    A continuación se muestra un ejemplo de resultados:

    $ 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. Elimine el secreto del certificado de servicio de Dex actual para que cert-manager lo vuelva a crear:

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

    A continuación se muestra un ejemplo de resultados:

    secret "dex-cert-tls" deleted

  7. Compruebe que se haya creado un nuevo certificado de servicio de Dex:

    kubectl get secret -n tanzu-system-auth

    A continuación se muestra un ejemplo de resultados:

    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. Elimine el trabajo posterior a la implementación de Pinniped:

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

    A continuación se muestra un ejemplo de resultados:

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

  9. Actualice el complemento Pinniped para sincronizar los cambios rápidamente y espere unos minutos hasta que el complemento concilie los cambios:

    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. Descargue el nuevo certificado de CA 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

    Donde NEW-FILE es el nombre en el que desea guardar el archivo de texto del certificado de CA Dex, por ejemplo, ca-after.txt.

  11. Descargue el nuevo certificado de servicio de Dex:

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

    Donde:

    • ADDRESS es la dirección del servicio de Dex en Tanzu Kubernetes Grid.

    • NEW-FILE es el nombre en el que desea guardar el nuevo archivo de texto del certificado de servicio de Dex, por ejemplo, after.txt.

    • Descargue los nuevos datos de CA 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

    Donde NEW-FILE es el nombre en el que desea guardar el archivo de texto del datos de CA Dex, por ejemplo, ca-data-after.txt.

  12. Compare los certificados antiguos y nuevos de CA para asegurarse de que se haya creado el certificado nuevo de CA:

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

    Donde:

    • OLD-FILE es el nombre del certificado de CA Dex antiguo.
    • NEW-FILE es el nombre del certificado de CA Dex antiguo.

  13. Compare los certificados antiguos y nuevos de servicio para asegurarse de que se haya creado el certificado nuevo de servicio:

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

    Donde:

    • OLD-FILE es el nombre del certificado de servicio de Dex anterior.
    • NEW-FILE es el nombre del certificado de servicio de Dex anterior.

  14. Compare los datos antiguos y nuevos de CA para asegurarse de que se hayan creado los datos nuevos de CA:

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

    Donde:

    • OLD-FILE es el nombre del archivo de datos de CA Dex antiguo.
    • NEW-FILE es el nombre del archivo de datos de CA Dex antiguo.
check-circle-line exclamation-circle-line close-line
Scroll to top icon