vSphere IaaS control plane utiliza el cifrado de seguridad de la capa de transporte (Transport Layer Security, TLS) para proteger las comunicaciones entre los componentes. TKG en Supervisor incluye varios certificados TLS que admiten esta infraestructura criptográfica. La rotación de certificados de Supervisor es manual. La rotación de certificados de TKG está automatizada, pero se puede hacer manualmente si es necesario.

Acerca de los certificados TLS para clústeres del servicio TKG

vSphere IaaS control plane utiliza certificados TLS para proteger la comunicación entre los siguientes componentes:
  • vCenter Server
  • Nodos del plano de control de Supervisor
  • Los hosts ESXi funcionan como nodos de trabajo para los pods de vSphere
  • Nodos del clúster de TKG, tanto del plano de control como de trabajo
vSphere IaaS control plane funciona en los siguientes dominios de confianza para autenticar a los usuarios del sistema.
Dominio de confianza Descripción
Dominio de confianza de vCenter El firmante predeterminado de los certificados TLS en este dominio de confianza es la instancia de VMware Certificate Authority (VMCA) que está integrada en vCenter Server.
Dominio de confianza de Kubernetes El firmante predeterminado de los certificados TLS en este dominio de confianza es la entidad de certificación (Certificate Authority, CA) de Kubernetes.
Consulte el artículo de la base de conocimientos Guía de certificación de vSphere with Tanzu para conocer más detalles y las listas completas de cada certificado TLS que se utiliza en el entorno de vSphere IaaS control plane.

Rotación de certificados TLS

El procedimiento para rotar certificados TLS varía en función de si los certificados se utilizan para Supervisor o para clústeres del servicio TKG.
Rotación de certificados de supervisor

Los certificados TLS para Supervisor se derivan del certificado de VMCA. Consulte el artículo de la base de conocimientos Guía de certificación de vSphere with Tanzu para ver más detalles sobre los certificados de Supervisor.

La rotación de certificados para Supervisor es manual. Consulte el artículo de la base de conocimientos Reemplazar los certificados de supervisor para vSphere with Tanzu si desea obtener instrucciones sobre cómo reemplazar los certificados de Supervisor mediante la herramienta del administrador de certificados de WCP.

Rotación de certificados del clúster de TKG 2.0

Por lo general, no es necesario rotar manualmente los certificados TLS de un clúster de TKG, ya que cuando se actualiza un clúster de TKG, el proceso de actualización gradual se encarga de rotar automáticamente los certificados TLS.

Si los certificados TLS de un clúster de TKG no han caducado y necesita rotar manualmente estos certificados, puede hacerlo. Para ello, debe completar los pasos que se muestran en la siguiente sección.

Rotar manualmente los certificados TLS para un clúster del servicio TKG

En estas instrucciones se da por hecho que se tiene experiencia y conocimientos avanzados de la administración de clústeres de TKG. Además, en estas instrucciones se supone que los certificados TLS no caducaron. Si los certificados están caducados, no lleve a cabo estos pasos.
  1. Para ejecutar estos pasos, utilice SSH en uno de los nodos del Supervisor. Consulte Conectarse a clústeres de Servicio TKG como usuario del sistema y administrador de Kubernetes.
  2. Obtenga el nombre del clúster de TKG.
    export CLUSTER_NAMESPACE="tkg-cluster-ns"

kubectl get clusters -n $CLUSTER_NAMESPACE
NAME                    PHASE         AGE   VERSION
tkg-cluster             Provisioned   43h
  3. Obtenga el clúster de TKG kubeconfig.
    export CLUSTER_NAME="tkg-cluster"

kubectl get secrets -n $CLUSTER_NAMESPACE $CLUSTER_NAME-kubeconfig -o jsonpath='{.data.value}' | base64 -d > $CLUSTER_NAME-kubeconfig
  4. Obtenga la clave SSH del clúster de TKG.
    kubectl get secrets -n $CLUSTER_NAMESPACE $CLUSTER_NAME-ssh -o jsonpath='{.data.ssh-privatekey}' | base64 -d > $CLUSTER_NAME-ssh-privatekey
chmod 600 $CLUSTER_NAME-ssh-privatekey
  5. Compruebe el entorno antes de la rotación de certificados.
    export KUBECONFIG=$CLUSTER_NAME-kubeconfig
    kubectl get nodes -o wide
    kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes
    for i in `cat nodes`; do
    printf "\n######\n"
    ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname
    ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo kubeadm certs check-expiration
done;

    Ejemplo de resultado de los comandos anteriores:

    tkg-cluster-control-plane-k8bqh
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Oct 04, 2023 23:00 UTC   363d                                    no
apiserver                  Oct 04, 2023 23:00 UTC   363d            ca                      no
apiserver-etcd-client      Oct 04, 2023 23:00 UTC   363d            etcd-ca                 no
apiserver-kubelet-client   Oct 04, 2023 23:00 UTC   363d            ca                      no
controller-manager.conf    Oct 04, 2023 23:00 UTC   363d                                    no
etcd-healthcheck-client    Oct 04, 2023 23:00 UTC   363d            etcd-ca                 no
etcd-peer                  Oct 04, 2023 23:00 UTC   363d            etcd-ca                 no
etcd-server                Oct 04, 2023 23:00 UTC   363d            etcd-ca                 no
front-proxy-client         Oct 04, 2023 23:00 UTC   363d            front-proxy-ca          no
scheduler.conf             Oct 04, 2023 23:00 UTC   363d                                    no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Oct 01, 2032 22:56 UTC   9y              no
etcd-ca                 Oct 01, 2032 22:56 UTC   9y              no
front-proxy-ca          Oct 01, 2032 22:56 UTC   9y              no
  6. Rote los certificados TLS para el clúster de TKG 2.0.
    Cambie el contexto al Supervisor antes de continuar con los siguientes pasos. 
    unset KUBECONFIG
kubectl config current-context
kubernetes-admin@kubernetes
    kubectl get kcp  -n $CLUSTER_NAMESPACE $CLUSTER_NAME-control-plane -o jsonpath='{.apiVersion}{"\n"}'
controlplane.cluster.x-k8s.io/v1beta1
    kubectl get kcp -n $CLUSTER_NAMESPACE $CLUSTER_NAME-control-plane
NAME                        CLUSTER       INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE   VERSION
tkg-cluster-control-plane   tkg-cluster   true          true                   3          3       3         0             43h   v1.21.6+vmware.1

    kubectl patch kcp $CLUSTER_NAME-control-plane -n $CLUSTER_NAMESPACE --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}"
kubeadmcontrolplane.controlplane.cluster.x-k8s.io/tkg-cluster-control-plane patched
    Se inició la implementación de la máquina: 
    kubectl get machines -n $CLUSTER_NAMESPACE
NAME                                              CLUSTER       NODENAME                                          PROVIDERID                                       PHASE          AGE   VERSION
tkg-cluster-control-plane-k8bqh                   tkg-cluster   tkg-cluster-control-plane-k8bqh                   vsphere://420a2e04-cf75-9b43-f5b6-23ec4df612eb   Running        43h   v1.21.6+vmware.1
tkg-cluster-control-plane-l7hwd                   tkg-cluster   tkg-cluster-control-plane-l7hwd                   vsphere://420a57cd-a1a0-fec6-a741-19909854feb6   Running        43h   v1.21.6+vmware.1
tkg-cluster-control-plane-mm6xj                   tkg-cluster   tkg-cluster-control-plane-mm6xj                   vsphere://420a67c2-ce1c-aacc-4f4c-0564daad4efa   Running        43h   v1.21.6+vmware.1
tkg-cluster-control-plane-nqdv6                   tkg-cluster                                                                                                      Provisioning   25s   v1.21.6+vmware.1
tkg-cluster-workers-v8575-59c6645b4-wvnlz         tkg-cluster   tkg-cluster-workers-v8575-59c6645b4-wvnlz         vsphere://420aa071-9ac2-02ea-6530-eb59ceabf87b   Running        43h   v1.21.6+vmware.1
    Se completó la implementación de la máquina: 
    kubectl get machines -n $CLUSTER_NAMESPACE
NAME                                              CLUSTER       NODENAME                                          PROVIDERID                                       PHASE     AGE   VERSION
tkg-cluster-control-plane-m9745                   tkg-cluster   tkg-cluster-control-plane-m9745                   vsphere://420a5758-50c4-3172-7caf-0bbacaf882d3   Running   17m   v1.21.6+vmware.1
tkg-cluster-control-plane-nqdv6                   tkg-cluster   tkg-cluster-control-plane-nqdv6                   vsphere://420ad908-00c2-4b9b-74d8-8d197442e767   Running   22m   v1.21.6+vmware.1
tkg-cluster-control-plane-wdmph                   tkg-cluster   tkg-cluster-control-plane-wdmph                   vsphere://420af38a-f9f8-cb21-e05d-c1bcb6840a93   Running   10m   v1.21.6+vmware.1
tkg-cluster-workers-v8575-59c6645b4-wvnlz         tkg-cluster   tkg-cluster-workers-v8575-59c6645b4-wvnlz         vsphere://420aa071-9ac2-02ea-6530-eb59ceabf87b   Running   43h   v1.21.6+vmware.1
  7. Compruebe la rotación manual de certificados para el clúster de TKG 2.0.
    Ejecute los siguientes comandos para comprobar la rotación de certificados: 
    export KUBECONFIG=$CLUSTER_NAME-kubeconfig

kubectl get nodes -o wide
NAME                                        STATUS   ROLES                  AGE     VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                 KERNEL-VERSION       CONTAINER-RUNTIME
tkg-cluster-control-plane-m9745             Ready    control-plane,master   15m     v1.21.6+vmware.1   10.244.0.55   <none>        VMware Photon OS/Linux   4.19.198-1.ph3-esx   containerd://1.4.11
tkg-cluster-control-plane-nqdv6             Ready    control-plane,master   21m     v1.21.6+vmware.1   10.244.0.54   <none>        VMware Photon OS/Linux   4.19.198-1.ph3-esx   containerd://1.4.11
tkg-cluster-control-plane-wdmph             Ready    control-plane,master   9m22s   v1.21.6+vmware.1   10.244.0.56   <none>        VMware Photon OS/Linux   4.19.198-1.ph3-esx   containerd://1.4.11
tkg-cluster-workers-v8575-59c6645b4-wvnlz   Ready    <none>                 43h     v1.21.6+vmware.1   10.244.0.51   <none>        VMware Photon OS/Linux   4.19.198-1.ph3-esx   containerd://1.4.11

kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes

for i in `cat nodes`; do
    printf "\n######\n"
    ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname
    ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo kubeadm certs check-expiration
done;
    Ejemplo de resultado donde se muestran las fechas de caducidad actualizadas. 
    ######
tkg-cluster-control-plane-m9745
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Oct 06, 2023 18:18 UTC   364d                                    no
apiserver                  Oct 06, 2023 18:18 UTC   364d            ca                      no
apiserver-etcd-client      Oct 06, 2023 18:18 UTC   364d            etcd-ca                 no
apiserver-kubelet-client   Oct 06, 2023 18:18 UTC   364d            ca                      no
controller-manager.conf    Oct 06, 2023 18:18 UTC   364d                                    no
etcd-healthcheck-client    Oct 06, 2023 18:18 UTC   364d            etcd-ca                 no
etcd-peer                  Oct 06, 2023 18:18 UTC   364d            etcd-ca                 no
etcd-server                Oct 06, 2023 18:18 UTC   364d            etcd-ca                 no
front-proxy-client         Oct 06, 2023 18:18 UTC   364d            front-proxy-ca          no
scheduler.conf             Oct 06, 2023 18:18 UTC   364d                                    no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Oct 01, 2032 22:56 UTC   9y              no
etcd-ca                 Oct 01, 2032 22:56 UTC   9y              no
front-proxy-ca          Oct 01, 2032 22:56 UTC   9y              no
  8. Compruebe el certificado de Kubelet.

    No es necesario rotar el certificado de Kubelet si se da por hecho que el parámetro rotateCertificates en la configuración de kubelet está establecido en true, que es la configuración predeterminada.

    Esta configuración se puede verificar mediante los siguientes comandos: 
    kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
-l node-role.kubernetes.io/master!= > workernodes

for i in `cat workernodes`; do
    printf "\n######\n"
    ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname
    ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo grep rotate /var/lib/kubelet/config.yaml
done;
    Resultado de ejemplo: 
    ######
tkg-cluster-workers-v8575-59c6645b4-wvnlz
rotateCertificates: true