vSphere IaaS control plane utilise le chiffrement TLS (Transport Layer Security) pour sécuriser les communications entre les composants. TKG sur le Superviseur inclut plusieurs certificats TLS prenant en charge cette infrastructure de chiffrement. La rotation des certificats du Superviseur est manuelle. La rotation des certificats TKG est automatisée, mais peut être effectuée manuellement si nécessaire.

À propos des certificats TLS pour les clusters de services TKG

vSphere IaaS control plane utilise des certificats TLS pour sécuriser la communication entre les composants suivants :
  • vCenter Server
  • Nœuds de plan de contrôle du Superviseur
  • Hôtes ESXi fonctionnant en tant que nœuds worker pour les Espaces vSphere
  • Nœuds de cluster TKG (de plan de contrôle et worker)
vSphere IaaS control plane fonctionne dans les domaines d'approbation suivants pour authentifier les utilisateurs du système.
Domaine d'approbation Description
Domaine d'approbation vCenter Le signataire par défaut des certificats TLS dans ce domaine d'approbation est l'autorité de certification VMware (VMCA, VMware Certificate Authority) intégrée dans vCenter Server.
Domaine d'approbation Kubernetes Le signataire par défaut des certificats TLS dans ce domaine d'approbation est l'autorité de certification (CA) Kubernetes.
Reportez-vous à l'article de la base de connaissances Guide des certificats vSphere with Tanzu pour obtenir des informations supplémentaires et des listes complètes sur chaque certificat TLS utilisé dans l'environnement vSphere IaaS control plane.

Rotation des certificats TLS

La procédure de rotation des certificats TLS diffère selon que les certificats sont utilisés pour le Superviseur ou pour les clusters de services TKG.
Rotation des certificats du superviseur

Les certificats TLS pour le Superviseur sont dérivés du certificat VMCA. Reportez-vous à l'article de la base de connaissances Guide des certificats vSphere with Tanzu pour plus d'informations sur les certificats du Superviseur.

La rotation des certificats pour le Superviseur est manuelle. Reportez-vous à l'article de la base de connaissances Remplacer les certificats de superviseur vSphere with Tanzu pour obtenir des instructions sur le remplacement des certificats de Superviseur à l'aide de l'outil Gestionnaire de certificats WCP.

Rotation des certificats de cluster TKG 2.0

En général, vous n'avez pas besoin d'effectuer une rotation manuelle des certificats TLS pour un cluster TKG, car le processus de mise à jour continue effectue automatiquement la rotation des certificats TLS à votre place lorsque vous mettez à jour un cluster TKG.

Si les certificats TLS d'un cluster TKG n'ont pas expiré et que vous devez effectuer une rotation manuelle de ces certificats, vous pouvez procéder à cette opération en effectuant les étapes décrites dans la section suivante.

Rotation manuelle des certificats TLS pour un cluster de services TKG

Ces instructions supposent des connaissances avancées et une expérience de l'administration de clusters TKG. En outre, ces instructions supposent que les certificats TLS ne sont pas expirés. Si les certificats ont expiré, n'effectuez pas ces étapes.
  1. Pour exécuter ces étapes, connectez-vous via SSH à l'un des nœuds du Superviseur. Reportez-vous à la section Connexion à des clusters Service TKG en tant qu'administrateur Kubernetes et utilisateur système.
  2. Obtenez le nom du cluster TKG.
    export CLUSTER_NAMESPACE="tkg-cluster-ns"

kubectl get clusters -n $CLUSTER_NAMESPACE
NAME                    PHASE         AGE   VERSION
tkg-cluster             Provisioned   43h
  3. Obtenez le fichier kubeconfig du 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. Obtenez la clé SSH du 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. Vérifiez l’environnement avant la rotation des certificats.
    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;

    Exemple de résultat des commandes précédentes :

    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. Effectuez une rotation des certificats TLS pour le cluster TKG 2.0.
    Revenez au contexte du Superviseur avant d'effectuer les étapes suivantes. 
    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
    Démarrage du déploiement de la machine : 
    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
    Déploiement de la machine terminé : 
    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. Vérifiez la rotation manuelle des certificats pour le cluster TKG 2.0.
    Exécutez les commandes suivantes pour vérifier la rotation des certificats : 
    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;
    Exemple de résultat indiquant les dates d’expiration mises à jour. 
    ######
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. Vérifiez le certificat Kubelet.

    Il n'est pas nécessaire d'effectuer la rotation du certificat Kubelet en supposant que le paramètre rotateCertificates dans la configuration de Kubelet est défini sur true, ce qui est la configuration par défaut.

    Cette configuration peut être vérifiée à l'aide des commandes suivantes : 
    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;
    Exemple de résultat : 
    ######
tkg-cluster-workers-v8575-59c6645b4-wvnlz
rotateCertificates: true