Gérer les secrets de cluster

Cette rubrique explique comment configurer et gérer les secrets utilisés par les clusters de charge de travail dans Tanzu Kubernetes Grid, notamment :

• Les informations d'identification que les clusters utilisent pour accéder aux API et aux ressources de l'infrastructure cloud. Reportez-vous à la section Mettre à jour les informations d'identification du cluster.
• Certificats clients que les composants internes du cluster utilisent pour authentifier les demandes (clusters de charge de travail déployés par un cluster de gestion autonome uniquement). Reportez-vous à la section Renouveler les certificats du cluster.
• Les certificats d'autorité de certification (CA) que les clusters utilisent pour accéder aux registres de conteneur privé. Reportez-vous aux sections Configurer des clusters avec plusieurs registres approuvés et Ajouter une approbation de certificat d'autorité de certification personnalisé aux clusters existants.
• Les informations d'identification que les clusters utilisent pour accéder aux registres de conteneur privé authentifiés. Reportez-vous à la section Configurer l'authentification dans un registre de conteneur privé.

Mettre à jour les informations d'identification du cluster

Si les informations d'identification que vous utilisez pour accéder à vSphere ou Azure sont modifiées, vous pouvez mettre à jour vos clusters afin d'utiliser les nouvelles informations d'identification. AWS gère les informations d'identification différemment. Cette section ne s'applique donc qu'à vSphere et Azure.

vSphere

Mettre à jour les informations d'identification du cluster de gestion autonome et de charge de travail

Pour mettre à jour les informations d'identification vSphere utilisées par le cluster de gestion autonome actuel et par tous ses clusters de charge de travail, utilisez la commande tanzu mc credentials update --cascading :

1. Exécutez tanzu context use MGMT-CLUSTER pour vous connecter au cluster de gestion que vous mettez à jour.

2. Exécutez tanzu mc credentials update. Vous pouvez transmettre des valeurs aux options de commande suivantes ou laisser la CLI vous y inviter :

   • --vsphere-user : nom du compte vSphere.
   • --vsphere-password : mot de passe du compte vSphere.
   • --vsphere-thumbprint : Empreinte numérique TLS de l'instance de vCenter Server.

Mettre à jour les informations d'identification du cluster de gestion autonome uniquement

Pour mettre à jour les informations d'identification vSphere d'un cluster de gestion autonome sans les mettre également à jour pour ses clusters de charge de travail, utilisez la commande tanzu mc credentials update comme décrit ci-dessus, mais sans l'option --cascading.

Mettre à jour les informations d'identification du cluster de charge de travail

Pour mettre à jour les informations d'identification qu'un cluster de charge de travail unique utilise pour accéder à vSphere, utilisez la commande tanzu cluster credentials update :

1. Exécutez tanzu context use MGMT-CLUSTER pour vous connecter au cluster de gestion qui a créé le cluster de charge de travail que vous mettez à jour. Le cluster de gestion peut être le cluster superviseur ou le cluster de gestion autonome.

2. Exécutez tanzu cluster credentials update CLUSTER-NAME. Vous pouvez transmettre des valeurs aux options de commande suivantes ou laisser la CLI vous y inviter :

   • --namespace : espace de noms du cluster pour lequel vous mettez à jour les informations d'identification telles que default.
   • --vsphere-user : nom du compte vSphere.
   • --vsphere-password : mot de passe du compte vSphere.
   • --vsphere-thumbprint : Empreinte numérique TLS de l'instance de vCenter Server.

Vous pouvez également utiliser tanzu mc credentials update --cascading pour mettre à jour les informations d'identification vSphere d'un cluster de gestion et de tous les clusters de charge de travail qu'il gère.

AWS

Cette section ne s'applique pas aux déploiements AWS.

Azure

Mettre à jour les informations d'identification du cluster de gestion autonome et de charge de travail

Important

Avant de commencer, procurez-vous les nouvelles informations d'identification Azure depuis le portail Azure ou auprès de votre administrateur Azure.

Pour mettre à jour les informations d'identification Azure utilisées par le cluster de gestion autonome actuel et par tous ses clusters de charge de travail, utilisez la commande tanzu mc credentials update --cascading :

1. Exécutez tanzu context use MGMT-CLUSTER pour vous connecter au cluster de gestion que vous mettez à jour.

2. Exécutez tanzu mc credentials update. Vous pouvez transmettre des valeurs aux options de commande suivantes ou laisser la CLI vous y inviter :

   • --azure-client-id : ID client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.
   • --azure-client-secret : Clé secrète client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.
   • --azure-tenant-id : ID de locataire Azure pour l'instance d'Active Directory dans laquelle se trouve l'application pour Tanzu Kubernetes Grid.

Mettre à jour les informations d'identification du cluster de gestion autonome uniquement

Pour mettre à jour les informations d'identification Azure d'un cluster de gestion autonome sans les mettre également à jour pour ses clusters de charge de travail, utilisez la commande tanzu mc credentials update comme décrit ci-dessus, mais sans l'option --cascading.

Mettre à jour les informations d'identification du cluster de charge de travail

Pour mettre à jour les informations d'identification qu'un cluster de charge de travail unique utilise pour accéder à Azure, utilisez la commande tanzu cluster credentials update :

1. Exécutez tanzu context use MGMT-CLUSTER pour vous connecter au cluster de gestion qui a créé le cluster de charge de travail que vous mettez à jour.

2. Exécutez tanzu cluster credentials update CLUSTER-NAME. Vous pouvez transmettre des valeurs aux options de commande suivantes ou laisser la CLI vous y inviter :

   • --namespace : espace de noms du cluster pour lequel vous mettez à jour les informations d'identification telles que default.
   • --azure-client-id : ID client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.
   • --azure-client-secret : Clé secrète client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.
   • --azure-tenant-id : ID de locataire Azure pour l'instance d'Active Directory dans laquelle se trouve l'application pour Tanzu Kubernetes Grid.

Vous pouvez également utiliser tanzu mc credentials update --cascading pour mettre à jour les informations d'identification Azure d'un cluster de gestion et de tous les clusters de charge de travail qu'il gère.

Renouvellement automatique du certificat de nœud de plan de contrôle

Configurez les clusters TKG pour renouveler automatiquement leurs certificats de machine virtuelle de nœud de plan de contrôle comme suit, en fonction de la méthode de configuration et du type de cluster :

• Spécification d'objet de style Kubernetes (clusters basés sur une classe) :

  • Dans la spécification d'objet Cluster, incluez le bloc suivant sous spec.topology.variables :

    - name: controlPlaneCertificateRotation.activate
    value: true
    - name: controlPlaneCertificateRotation.daysBefore
    value: EXPIRY-DAYS
    

• Fichier de configuration de cluster plat (clusters basés sur une classe ou hérités) :

  • Dans votre fichier de configuration de cluster, incluez les paramètres suivants :

    CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
    CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
    

Où EXPIRY-DAYS est un paramètre facultatif correspondant au nombre de jours avant la date d'expiration du certificat pour renouveler automatiquement les certificats de nœud de cluster. Défaut : 90 ; minimum : 7.

Renouveler les certificats de cluster (MC autonome)

Les clusters de gestion autonomes et leurs clusters de charge de travail utilisent des certificats clients pour authentifier les demandes. Ces certificats sont valides pendant un an. Pour les renouveler, vous pouvez mettre à niveau vos clusters ou suivre la procédure ci-dessous. Cette procédure est destinée aux certificats de cluster qui n'ont pas expiré et qui sont toujours valides.

1. Identifiez le cluster pour lequel vous souhaitez renouveler ses certificats. Par exemple :

   tanzu cluster list
   NAME                 NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
   workload-slot35rp10  default    running  3/3           3/3      v1.27.5+vmware.1  <none>  prod  v1.27.5---vmware.2-tkg.1
   

   Pour répertorier les nœuds de cluster, exécutez :

   kubectl get nodes -o wide
   

2. Vérifiez la date d'expiration des certificats :

   vSphere

   Exécutez la commande suivante.

   kubectl get nodes \
   -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
   -l node-role.kubernetes.io/master= > nodes
   
   for i in `cat nodes`; do
      printf "\n######\n"
      ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
      ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
   done;
   

   AWS

   Exécutez la commande suivante.

   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 -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i hostname
       ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i sudo kubeadm certs check-expiration
   done;
   

   Azure

   Exécutez la commande suivante.

   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 -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i hostname
       ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i sudo kubeadm certs check-expiration
   done;
   

   Exemple de résultat :

   ######
   workload-slot35rp10-control-plane-ggsmj
   [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'
   W0923 17:51:03.686273 4172778 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
   
   CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
   admin.conf                 Sep 21, 2023 23:13 UTC   363d            ca                      no
   apiserver                  Sep 21, 2023 23:13 UTC   363d            ca                      no
   apiserver-etcd-client      Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
   apiserver-kubelet-client   Sep 21, 2023 23:13 UTC   363d            ca                      no
   controller-manager.conf    Sep 21, 2023 23:13 UTC   363d            ca                      no
   etcd-healthcheck-client    Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
   etcd-peer                  Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
   etcd-server                Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
   front-proxy-client         Sep 21, 2023 23:13 UTC   363d            front-proxy-ca          no
   scheduler.conf             Sep 21, 2023 23:13 UTC   363d            ca                      no
   
   CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
   ca                      Sep 18, 2032 23:09 UTC   9y              no
   etcd-ca                 Sep 18, 2032 23:09 UTC   9y              no
   front-proxy-ca          Sep 18, 2032 23:09 UTC   9y              no
   

3. Définissez votre contexte kubectl sur le cluster de gestion. Par exemple :

   kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
   

4. Obtenez le nom de l'objet KCP pour votre cluster cible. Par exemple :

   kubectl get kcp
   
   NAME                                CLUSTER               INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE   VERSION
   workload-slot35rp10-control-plane   workload-slot35rp10   true          true                   3          3       3         0             42h   v1.27.5+vmware.1
   

5. Renouvelez les certificats en déclenchant le déploiement d'un plan de contrôle :

   kubectl patch kcp workload-slot35rp10-control-plane --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}
   

   Après avoir exécuté cette commande, Tanzu Kubernetes Grid commence à reprovisionner vos machines de cluster :

   kubectl get machines
   
   workload-slot35rp10-control-plane-7z95k     workload-slot35rp10                                                                                                Provisioning   20s   v1.27.5+vmware.1
   workload-slot35rp10-control-plane-ggsmj     workload-slot35rp10   workload-slot35rp10-control-plane-ggsmj     vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f   Running        42h   v1.27.5+vmware.1
   workload-slot35rp10-control-plane-hxbxb     workload-slot35rp10   workload-slot35rp10-control-plane-hxbxb     vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd   Running        42h   v1.27.5+vmware.1
   workload-slot35rp10-control-plane-sm4nw     workload-slot35rp10   workload-slot35rp10-control-plane-sm4nw     vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce   Running        42h   v1.27.5+vmware.1
   workload-slot35rp10-md-0-667bcd6b57-79br9   workload-slot35rp10   workload-slot35rp10-md-0-667bcd6b57-79br9   vsphere://420142a2-d141-7d6b-b322-9c2afcc47da5   Running        42h   v1.27.5+vmware.1
   ...
   

6. Lorsque toutes les machines sont à l'état Running, vérifiez que le renouvellement du certificat est terminé :

   1. Définissez votre contexte kubectl sur le cluster de charge de travail :

      kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
      

   2. Vérifiez à nouveau la date d'expiration des certificats :

      kubectl get nodes \
      -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
      -l node-role.kubernetes.io/master= > nodes
      
      for i in `cat nodes`; do
        printf "\n######\n"
        ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
        ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
      done;
      

      Exemple de résultat :

      ######
      workload-slot35rp10-control-plane-4xgw8
      [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'
      
      W0923 18:10:02.660438   13427 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
      CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
      admin.conf                 Sep 23, 2023 18:05 UTC   364d            ca                      no
      apiserver                  Sep 23, 2023 18:05 UTC   364d            ca                      no
      apiserver-etcd-client      Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      apiserver-kubelet-client   Sep 23, 2023 18:05 UTC   364d            ca                      no
      controller-manager.conf    Sep 23, 2023 18:05 UTC   364d            ca                      no
      etcd-healthcheck-client    Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      etcd-peer                  Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      etcd-server                Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      front-proxy-client         Sep 23, 2023 18:05 UTC   364d            front-proxy-ca          no
      scheduler.conf             Sep 23, 2023 18:05 UTC   364d            ca                      no
      
      CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
      ca                      Sep 18, 2032 23:09 UTC   9y              no
      etcd-ca                 Sep 18, 2032 23:09 UTC   9y              no
      front-proxy-ca          Sep 18, 2032 23:09 UTC   9y              no
      

      Si le renouvellement du certificat s'est correctement terminé, la colonne Residual Time indique 364d. Les certificats sur les nœuds worker sont renouvelés automatiquement.

Configurer des clusters avec des registres approuvés (superviseur)

Pour configurer un cluster TKG déployé par le superviseur afin qu'il utilise un registre de conteneur privé externe à TKG, c'est-à-dire un registre avec un certificat auto-signé qui ne s'exécute pas dans un cluster TKG, reportez-vous aux rubriques suivantes de la documentation de vSphere :

• vSphere 8 : Intégrer un cluster TKG 2 à un registre de conteneur privé
• vSphere 7 : Utiliser un registre de conteneur externe avec les clusters Tanzu Kubernetes

Configurer des clusters avec plusieurs registres approuvés (MC autonome)

Dans un environnement à accès restreint à Internet avec un cluster de gestion autonome, vous pouvez configurer des variables TKG_CUSTOM_IMAGE_REPOSITORY_* pour donner aux clusters TKG l'accès à un registre privé contenant des images système TKG à partir desquelles démarrer, par exemple une VM Harbor, comme décrit dans la section Déployer un registre Harbor hors ligne sur vSphere.

Les variables ADDITIONAL_IMAGE_REGISTRY_* configurent un nouveau cluster pour qu'il dispose de communications approuvées avec des registres supplémentaires qui utilisent des certificats d'autorité de certification (CA) auto-signés, par exemple :

• Registre privé qui sert de référentiel de modules pour l'installation de modules gérés par l'interface de ligne de commande (CLI).
• Registre Harbor auto-signé évolutif pour les images d'application hébergées sur TKG, déployé avec le module Harbor, comme décrit dans la section Installer Harbor pour le registre de service.
• Registre d'images auto-signé pour containerd, comme décrit dans la section Configurer le registre d'images du référentiel containerd.

La configuration des clusters pour approuver ces registres privés supplémentaires varie selon que le cluster est basé sur un plan ou sur une classe, comme décrit ci-dessous.

Registres approuvés pour un cluster basé sur une classe

Pour configurer un cluster de charge de travail basé sur une classe ou un cluster de gestion autonome avec approbation pour des registres d'images personnalisés supplémentaires, définissez les variables comme ci-dessous pour trois registres d'images supplémentaires au maximum :

• Pour configurer plus de trois registres, configurez les trois premiers, comme ci-dessous à l'étape 1 d'un processus en deux étapes décrit dans la section Créer un cluster basé sur une classe, puis suivez Définir une approbation de cluster basé sur une classe comme registre personnalisé ci-dessous pour ajouter d'autres registres au manifeste généré avant de créer le cluster à l'étape 2.

  ADDITIONAL_IMAGE_REGISTRY_1: "OTHER-REGISTRY-1"
  ADDITIONAL_IMAGE_REGISTRY_1_SKIP_TLS_VERIFY: false
  ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE: "CA-BASE64-1"
  
  ADDITIONAL_IMAGE_REGISTRY_2: "OTHER-REGISTRY-2"
  ADDITIONAL_IMAGE_REGISTRY_2_SKIP_TLS_VERIFY: false
  ADDITIONAL_IMAGE_REGISTRY_2_CA_CERTIFICATE: "CA-BASE64-2"
  
  ADDITIONAL_IMAGE_REGISTRY_3: "OTHER-REGISTRY-3"
  ADDITIONAL_IMAGE_REGISTRY_3_SKIP_TLS_VERIFY: false
  ADDITIONAL_IMAGE_REGISTRY_3_CA_CERTIFICATE: "CA-BASE64-3"
  

  Où OTHER-REGISTRY-<n> est l'adresse IP ou le nom de domaine complet d'un registre privé supplémentaire et CA-BASE64-<n> est son certificat d'autorité de certification au format codé en base64, sans préfixe http://. Cela est nécessaire, car ce fichier sera écrit sur le disque. Il doit donc s'agir d'un nom de fichier Unix normal.

Registres approuvés pour un nouveau cluster basé sur un plan

Pour permettre à un nouveau cluster TKC ou basé sur un plan d'extraire des images de registres de conteneur qui utilisent des certificats auto-signés, ajoutez les certificats personnalisés aux nœuds du cluster de charge de travail à l'aide d'un fichier de superposition ytt.

Le code de superposition ci-dessous ajoute des certificats d'autorité de certification personnalisés à tous les nœuds d'un nouveau cluster. Le code fonctionne sur toutes les plates-formes cibles, pour les clusters basés sur des modèles d'image de VM Photon ou Ubuntu.

Pour les superpositions qui personnalisent les clusters et créent un plan de cluster, reportez-vous à la section Superpositions ytt. Pour plus d'informations sur le téléchargement et l'installation de ytt, reportez-vous à la section Installer les outils Carvel.

1. Choisissez d'appliquer l'autorité de certification personnalisée à tous les nouveaux clusters, uniquement ceux créés sur une infrastructure de cloud ou ceux créés avec une version de fournisseur d'API de cluster spécifique, telle que le Fournisseur d'API du cluster vSphere v1.5.1.

2. Dans votre répertoire local ~/.config/tanzu/tkg/providers/, recherchez le répertoire ytt qui couvre la portée que vous avez choisie. Par exemple, /ytt/03_customizations/ s'applique à tous les clusters, et /infrastructure-vsphere/ytt/ s'applique à tous les clusters vSphere.

3. Dans le répertoire ytt que vous avez choisi, créez un fichier .yaml ou augmentez un fichier de superposition existant avec le code suivant :

   #@ load("@ytt:overlay", "overlay")
   #@ load("@ytt:data", "data")
   
   #! This ytt overlay adds additional custom CA certificates on TKG cluster nodes, so containerd and other tools trust these CA certificates.
   #! It works when using Photon or Ubuntu as the TKG node template on all TKG target platforms.
   
   #! Trust your custom CA certificates on all Control Plane nodes.
   #@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
   ---
   spec:
     kubeadmConfigSpec:
       #@overlay/match missing_ok=True
       files:
         #@overlay/append
         - content: #@ data.read("tkg-custom-ca.pem")
           owner: root:root
           permissions: "0644"
           path: /etc/ssl/certs/tkg-custom-ca.pem
       #@overlay/match missing_ok=True
       preKubeadmCommands:
         #! For Photon OS
         #@overlay/append
         - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
         #! For Ubuntu
         #@overlay/append
         - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
   
   #! Trust your custom CA certificates on all worker nodes.
   #@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}), expects="1+"
   ---
   spec:
     template:
       spec:
         #@overlay/match missing_ok=True
         files:
           #@overlay/append
           - content: #@ data.read("tkg-custom-ca.pem")
             owner: root:root
             permissions: "0644"
             path: /etc/ssl/certs/tkg-custom-ca.pem
         #@overlay/match missing_ok=True
         preKubeadmCommands:
           #! For Photon OS
           #@overlay/append
           - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
           #! For Ubuntu
           #@overlay/append
           - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
   

4. Dans le même répertoire ytt, ajoutez l'autorité de certification à un fichier tkg-custom-ca.pem nouveau ou existant.

5. Avant de créer le cluster, définissez la fonctionnalité allow-legacy-cluster sur true, comme décrit dans la section (Hérité) Créer un cluster basé sur un plan ou un cluster TKC.

Ajouter les certificats d'autorité de certification personnalisés approuvés aux clusters existants (MC autonome)

Vous pouvez activer la communication approuvée entre un cluster existant et des registres Harbor personnalisés supplémentaires avec des autorités de certification auto-signées, hormis celle définie par les variables de configuration TKG_CUSTOM_IMAGE_REPOSITORY_*, pour TLS containerd et d'autres utilisations. La procédure à effectuer varie selon que le cluster est basé sur un plan ou sur une classe, comme décrit ci-dessous.

Définir une approbation de cluster basé sur une classe comme registre personnalisé

Pour ajouter un registre personnalisé approuvé à un cluster existant basé sur une classe, modifiez son objet Cluster et ajoutez les paramètres additionalImageRegistries sous topology.variables dans la spécification d'objet :

topology:
  variables:
  - name: additionalImageRegistries
    value:
    - caCert: "CA-BASE64"
      host: OTHER-REGISTRY
      skipTlsVerify: false

Où :

• OTHER-REGISTRY est l'emplacement du registre privé supplémentaire, suivant le format : . Par exemple, 10.92.127.192:8443.
• CA-BASE64 est son certificat d'autorité de certification au format codé en base64, par exemple LS0tLS1CRU[...].

Pour ajouter une approbation à plusieurs registres, incluez plusieurs blocs de valeurs additionalImageRegistries.

Notez que les blocs topology.variables pour imageRepository et trust définissent les valeurs des variables de configuration TKG_CUSTOM_IMAGE_REPOSITORY_* et TKG_PROXY_CA_CERT.

Définir une approbation de cluster basé sur un plan comme registre personnalisé

Pour activer l'approbation entre un cluster existant basé sur un plan et un registre Harbor avec une autorité de certification auto-signée :

1. Récupérez le certificat d'autorité de certification Harbor :

   1. Changez de contexte vers le cluster exécutant Harbor, tel qu'un cluster de services partagés :

      kubectl config use-context SERVICES-CLUSTER-CONTEXT
      

      Où SERVICES-CLUSTER-CONTEXT est le contexte du cluster. Par exemple, tkg-wld-admin@tkg-wld.

   2. Récupérez le certificat :

      kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
      -----BEGIN CERTIFICATE-----
      MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
      [...]
      yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
      -----END CERTIFICATE-----
      

2. Ajoutez l'autorité de certification personnalisée au kubeadmconfigtemplate du cluster de gestion autonome :

   1. Changez de contexte vers le cluster de gestion.

      kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
      

      Où MANAGEMENT-CLUSTER-CONTEXT est le contexte de votre cluster de gestion. Par exemple, tkg-mgmt-admin@tkg-mgmt.

   2. Dans un éditeur, ouvrez le fichier de modèle kubeadmconfigtemplate du cluster :

      kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
      

      Où CLUSTER-NAME est le nom du cluster qui doit être modifié.

   3. Modifiez la section spec.template.spec.files du fichier pour inclure le certificat, comme indiqué ici :

      spec:
      template:
        spec:
          files:
          - content: |
                -----BEGIN CERTIFICATE-----
               MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
               [...]
               yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
               -----END CERTIFICATE-----
             owner: root:root
             path: /etc/ssl/certs/tkg-custom-ca.pem
             permissions: "0644"
      

   4. Au bas du fichier, ajoutez un bloc preKubeadmCommands comme indiqué ici :

      preKubeadmCommands:
      - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
      - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem
         /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
      

3. Enregistrez le fichier de modèle kubeadmconfigtemplate avec vos modifications.

4. Corrigez le cluster de gestion autonome avec les modifications suivantes :

   kubectl patch machinedeployments.cluster.x-k8s.io tkg-test-md-0 --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
   

   L'exécution de cette commande déclenche une mise à jour continue des nœuds de cluster et met à jour leur horodatage.

Configurer l'authentification dans un registre de conteneur privé

Vous pouvez ajouter des secrets d'authentification pour permettre à un cluster d'accéder à un registre de conteneur privé. Cela nécessite une authentification utilisateur pour extraire des images. Vous pouvez également afficher, mettre à jour ou supprimer les secrets d'authentification que vous avez configurés pour les registres privés accessibles par un cluster.

Ajouter un secret d'authentification pour un registre de conteneur privé

L'utilisation de la CLI Tanzu vous permet d'ajouter des secrets d'authentification pour accéder à un registre de conteneur privé à partir d'un cluster. Une fois le secret de registre ajouté aux espaces de noms de votre cluster, vous pouvez extraire tous les référentiels de modules, modules et images de conteneur qui sont hébergés dans le registre privé. Vous pouvez ajouter le référentiel de modules et les ressources de module à votre cluster.

Pour effectuer cette procédure, procurez-vous le nom d'utilisateur et le mot de passe du registre de conteneur privé.

Pour ajouter un secret d'authentification à un registre privé, exécutez la commande suivante :

tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD

Où :

• SECRET-NAME est le nom du secret d'authentification de registre que vous souhaitez ajouter.
• NAMESPACE est l'espace de noms Tanzu Kubernetes Grid auquel appartient le registre.
• USERNAME est le nom d'utilisateur permettant d'accéder au registre. Placez le nom d'utilisateur entre guillemets simples s'il contient des caractères spéciaux.

• PASSWORD est le mot de passe permettant d'accéder au registre. Placez le mot de passe entre guillemets simples s'il contient des caractères spéciaux. Vous pouvez également spécifier le mot de passe aux formats suivants :

  • Remplacez la chaîne --password PASSWORD dans la commande par --password-env-var ENV-VAR pour spécifier le mot de passe via la variable d'environnement que vous avez déjà configurée. Le format de cette commande est le suivant :

    tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-env-var ENV-VAR

  • Remplacez la chaîne --password PASSWORD dans la commande par la chaîne --password-stdin pour spécifier le mot de passe via une entrée standard et entrez le mot de passe lorsque vous y êtes invité. Le format de cette commande est le suivant :

    tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-stdin

  • Remplacez la chaîne --password PASSWORD de la commande par la chaîne --password-file PASSWORD-FILE pour spécifier le mot de passe via un fichier de mot de passe. Le format de cette commande est le suivant :

    tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-file PASSWORD-FILE

Pour rendre le secret de registre disponible dans tous les espaces de noms d'un cluster, vous pouvez également utiliser l'option --export-to-all-namespaces comme indiqué au format suivant :

tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD --export-to-all-namespaces

Voici un exemple de sortie de cette commande :

tanzu secret registry add tanzu-net -n test-ns --server registry.pivotal.io --username test-user --password-file pass-file --export-to-all-namespaces
Warning: By choosing --export-to-all-namespaces, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
/ Adding registry secret 'test-secret'...
  Added registry secret 'test-secret' into namespace 'test-ns'

Afficher les secrets d'authentification de registre dans un cluster

Vous pouvez afficher les secrets d'authentification de registre dans l'espace de noms par défaut ou dans tous les espaces de noms d'un cluster. Vous pouvez afficher les secrets sous la forme d'un tableau ou d'un fichier JSON ou YAML.

Pour afficher les secrets d'authentification de registre dans un espace de noms spécifique d'un cluster, exécutez les opérations suivantes :

tanzu secret registry list -n NAMESPACE

Où NAMESPACE est l'espace de noms Tanzu Kubernetes Grid auquel appartient le registre.

Voici un exemple de commande :

tanzu secret registry list -n test-ns
/ Retrieving registry secrets...
  NAME         REGISTRY                 EXPORTED           AGE
  pkg-dev-reg  registry.pivotal.io      to all namespaces  15d

Pour afficher la liste des secrets d'authentification de registre dans tous les espaces de noms d'un cluster, exécutez les opérations suivantes :

tanzu secret registry list -A

Voici un exemple de commande :

tanzu secret registry list -A
\ Retrieving registry secrets...
 NAME                          REGISTRY             EXPORTED           AGE  NAMESPACE
 pkg-dev-reg                   registry.pivotal.io  to all namespaces  15d  test-ns
 tanzu-standard-fetch-0        registry.pivotal.io  not exported       15d  tanzu-package-repo-global
 private-repo-fetch-0          registry.pivotal.io  not exported       15d  test-ns
 antrea-fetch-0                registry.pivotal.io  not exported       15d  tkg-system
 metrics-server-fetch-0        registry.pivotal.io  not exported       15d  tkg-system
 tanzu-addons-manager-fetch-0  registry.pivotal.io  not exported       15d  tkg-system
 tanzu-core-fetch-0            registry.pivotal.io  not exported       15d  tkg-system

Pour afficher la liste des secrets d'authentification de registre au format de fichier JSON, exécutez la commande suivante :

tanzu secret registry list -n kapp-controller-packaging-global -o json

Voici un exemple de commande :

tanzu secret registry list -n kapp-controller-packaging-global -o json
[
 {
   "age": "15d",
   "exported": "to all namespaces",
   "name": "pkg-dev-reg",
   "registry": "us-east4-docker.pkg.dev"
 }
]

Pour afficher la liste des secrets d'authentification de registre au format de fichier YAML, exécutez les commandes suivantes :

tanzu secret registry list -n kapp-controller-packaging-global -o yaml

Voici un exemple de commande :

 tanzu secret registry list -n kapp-controller-packaging-global -o yaml
 - age: 15d
   exported: to all namespaces
   name: pkg-dev-reg
   registry: us-east4-docker.pkg.dev

Pour afficher la liste des secrets d'authentification de registre dans un format de tableau, exécutez les commandes suivantes :

tanzu secret registry list -n kapp-controller-packaging-global -o table

Voici un exemple de commande :

tanzu secret registry list -n kapp-controller-packaging-global -o table
/ Retrieving registry secrets...
  NAME         REGISTRY                 EXPORTED           AGE
  pkg-dev-reg  us-east4-docker.pkg.dev  to all namespaces  15d

Mettre à jour un secret d'authentification de registre

Vous pouvez mettre à jour les informations d'identification dans un secret et rendre un secret disponible dans tous les espaces de noms, ou le rendre disponible dans un seul espace de noms du cluster.

Pour mettre à jour le secret dans l'espace de noms dans lequel il a été créé, exécutez la commande suivante :

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD

Où :

• SECRET-NAME est le nom du secret de registre que vous souhaitez mettre à jour.
• NAMESPACE est l'espace de noms Tanzu Kubernetes Grid dans lequel vous mettez à jour le secret d'authentification du registre.
• USERNAME est le nouveau nom d'utilisateur permettant d'accéder au registre (si vous souhaitez mettre à jour le nom d'utilisateur).
• PASSWORD est le nouveau mot de passe du registre (si vous souhaitez mettre à jour le mot de passe).

Remarque

vous pouvez mettre à jour le nom d'utilisateur ou le mot de passe, ou les deux.

Voici un exemple de commande :

tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV
\ Updating registry secret 'test-secret'...
 Updated registry secret 'test-secret' in namespace 'test-ns'

Pour mettre à jour le secret d'authentification du registre et le rendre disponible dans d'autres espaces de noms du cluster, exécutez la commande suivante :

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=true

Où :

• SECRET-NAME est le nom du secret de registre que vous souhaitez mettre à jour.
• NAMESPACE est l'espace de noms Tanzu Kubernetes Grid dans lequel vous mettez à jour le secret d'authentification du registre.
• USERNAME est le nom d'utilisateur permettant d'accéder au registre. Entrez un nouveau nom d'utilisateur si vous souhaitez mettre à jour le nom d'utilisateur.
• PASSWORD est le mot de passe du registre. Entrez un nouveau mot de passe si vous souhaitez mettre à jour le mot de passe.

Voici un exemple de commande :

tanzu secret registry update test-secret--username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=true
Warning: By specifying --export-to-all-namespaces as true, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
Are you sure you want to proceed? [y/N]: y

\ Updating registry secret 'test-secret'...
  Updated registry secret 'test-secret' in namespace 'test-ns'
  Exported registry secret 'test-secret' to all namespaces

Pour rendre un secret d'authentification de registre indisponible dans les autres espaces de noms du cluster, exécutez la commande suivante :

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=false

Où :

• SECRET-NAME est le nom du secret de registre que vous souhaitez mettre à jour.
• NAMESPACE est l'espace de noms Tanzu Kubernetes Grid dans lequel vous mettez à jour le secret d'authentification du registre.
• USERNAME est le nom d'utilisateur permettant d'accéder au registre.
• PASSWORD est le mot de passe du registre.

Voici un exemple de commande :

tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=false
Warning: By specifying --export-to-all-namespaces as false, the secret contents will get unexported from ALL namespaces in which it was previously available to.
Are you sure you want to proceed? [y/N]: y

\ Updating registry secret 'test-secret'...
  Updated registry secret 'test-secret' in namespace 'test-ns'
  Unexported registry secret 'test-secret' from all namespaces

Supprimer un secret d’authentification de registre

À l'aide de la CLI Tanzu, vous pouvez supprimer un secret d'authentification de registre dans un cluster. Pour supprimer un secret d'authentification de registre dans un espace de noms spécifique, exécutez la commande suivante :

tanzu secret registry delete SECRET-NAME -n NAMESPACE

Où :

• SECRET-NAME est le nom du secret de registre que vous souhaitez supprimer.
• (Facultatif) NAMESPACE est l'espace de noms Tanzu Kubernetes Grid à partir duquel vous souhaitez supprimer le secret d'authentification du registre. Si vous ne spécifiez pas d'espace de noms, le secret d'authentification est supprimé de l'espace de noms par défaut. Si le secret a été exporté vers d'autres espaces de noms dans le cluster, il est également supprimé.

Voici un exemple de commande :

tanzu secret registry delete test-secret -n test-ns
Deleting registry secret 'test-secret' from namespace 'test-ns'. Are you sure? [y/N]: y
\ Deleting registry secret 'test-secret'...
 Deleted registry secret 'test-secret' from namespace 'test-ns'