vSphere IaaS control plane utilizza la crittografia TLS (Transport Layer Security) per proteggere le comunicazioni tra componenti. TKG sul Supervisore include diversi certificati TLS che supportano questa infrastruttura crittografica. La rotazione del certificato del Supervisore è manuale. La rotazione del certificato TKG è automatizzata, ma può essere eseguita manualmente se necessario.

Informazioni sui certificati TLS per i cluster TKG Service

vSphere IaaS control plane utilizza certificati TLS per proteggere la comunicazione tra i seguenti componenti:
  • vCenter Server
  • Nodo del piano di controllo del Supervisore
  • Host ESXi funzionanti come nodi di lavoro per Pod vSphere
  • Nodi del cluster TKG, sia piano di controllo che di lavoro
vSphere IaaS control plane utilizza i seguenti domini di attendibilità per autenticare gli utenti del sistema.
Dominio di attendibilità Descrizione
Dominio di attendibilità vCenter Il firmatario predefinito per i certificati TLS in questo dominio di attendibilità è l'Autorità di certificazione VMware (VMCA) integrata in vCenter Server.
Dominio di attendibilità Kubernetes Il firmatario predefinito per i certificati TLS in questo dominio di attendibilità è l'Autorità di certificazione (CA) Kubernetes
Fare riferimento all'articolo della Knowledge Base vSphere with Tanzu Certificate Guide per ulteriori dettagli e per gli elenchi completi di ciascun certificato TLS utilizzato nell'ambiente vSphere IaaS control plane.

Rotazione del certificato TLS

La procedura per la rotazione dei certificati TLS varia a seconda che i certificati vengano utilizzati per Supervisore o per i cluster TKG Service.
Rotazione del certificato del Supervisore

I certificati TLS per il Supervisore derivano dal certificato VMCA. Per informazioni dettagliate sui certificati del Supervisore, fare riferimento all'articolo della Knowledge Base vSphere with Tanzu Certificate Guide.

La rotazione del certificato per il Supervisore è manuale. Fare riferimento all'articolo della Knowledge Base Replace vSphere with Tanzu Supervisor Certificates per istruzioni sulla sostituzione dei certificati del Supervisore utilizzando lo strumento Gestione certificati WCP.

Rotazione del certificato del cluster TKG 2.0

In genere non è necessario ruotare manualmente i certificati TLS per un cluster TKG perché quando si aggiorna un cluster TKG, il processo di aggiornamento in sequenza ruota automaticamente i certificati TLS.

Se i certificati TLS per un cluster TKG non sono scaduti ed è necessario ruotare manualmente tali certificati, è possibile farlo completando i passaggi nella sezione seguente.

Rotazione manuale dei certificati TLS per un cluster TKG Service

Queste istruzioni presuppongono conoscenza ed esperienza avanzate dell'amministrazione del cluster TKG da parte dell'utente. Inoltre, queste istruzioni presuppongono che i certificati TLS non siano scaduti. Se i certificati sono scaduti, non procedere con i passaggi descritti.
  1. Per eseguire questa procedura, accedere tramite SSH a uno dei nodi Supervisore. Vedere Connessione ai cluster Servizio TKG come amministratore di Kubernetes e utente di sistema.
  2. Recuperare il nome del cluster TKG.
    export CLUSTER_NAMESPACE="tkg-cluster-ns"

kubectl get clusters -n $CLUSTER_NAMESPACE
NAME                    PHASE         AGE   VERSION
tkg-cluster             Provisioned   43h
  3. Recuperare il kubeconfig del cluster TKG.
    export CLUSTER_NAME="tkg-cluster"

kubectl get secrets -n $CLUSTER_NAMESPACE $CLUSTER_NAME-kubeconfig -o jsonpath='{.data.value}' | base64 -d > $CLUSTER_NAME-kubeconfig
  4. Recuperare la chiave SSH del cluster 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. Controllare l'ambiente prima della rotazione del certificato.
    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;

    Risultato di esempio dei comandi precedenti:

    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. Ruotare i certificati TLS per il cluster TKG 2.0.
    Prima di procedere con i passaggi seguenti, tornare al Supervisore. 
    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
    Implementazione macchina avviata: 
    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
    Implementazione macchina completata: 
    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. Verificare la rotazione manuale del certificato per il cluster TKG 2.0.
    Eseguire i comandi seguenti per verificare la rotazione del certificato: 
    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;
    Risultato di esempio che mostra le date di scadenza aggiornate. 
    ######
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. Verificare il certificato Kubelet.

    Partendo dal presupposto che il parametro rotateCertificates nella configurazione kubelet sia impostato su true, ovvero la configurazione predefinita, non è necessario ruotare il certificato Kubelet.

    Questa configurazione può essere verificata utilizzando i comandi seguenti: 
    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;
    Risultato dell'esempio: 
    ######
tkg-cluster-workers-v8575-59c6645b4-wvnlz
rotateCertificates: true