Gestione dei segreti del cluster

Questo argomento spiega come configurare e gestire i segreti utilizzati dai cluster del carico di lavoro in Tanzu Kubernetes Grid tra cui:

• Credenziali utilizzate dai cluster per accedere alle API e alle risorse dell'infrastruttura cloud. Vedere Aggiornamento delle credenziali dei cluster.
• Certificati client utilizzati dai componenti interni del cluster per autenticare le richieste (solo per cluster del carico di lavoro distribuiti da cluster di gestione autonomi). Vedere Rinnovo dei certificati dei cluster.
• Certificati CA (Certificate Authority) utilizzati dai cluster per accedere ai registri dei container privati. Vedere Configurazione di cluster con più registri attendibili e Aggiunta di attendibilità dei certificati CA personalizzati ai cluster esistenti.
• Credenziali utilizzate dai cluster per accedere ai registri dei container privati autenticati. Vedere Configurazione dell'autenticazione in un registro di container privato.

Aggiornamento delle credenziali dei cluster

Se le credenziali utilizzate per accedere a vSphere o Azure cambiano, è possibile aggiornare i cluster in modo che utilizzino le nuove credenziali. AWS gestisce le credenziali in modo diverso, pertanto questa sezione si applica solo a vSphere e Azure.

vSphere

Aggiornamento delle credenziali del cluster di gestione autonomo e dei cluster del carico di lavoro

Per aggiornare le credenziali vSphere utilizzate dal cluster di gestione autonomo corrente e da tutti i relativi cluster del carico di lavoro, utilizzare il comando tanzu mc credentials update --cascading:

1. Eseguire tanzu context use MGMT-CLUSTER per accedere al cluster del carico di lavoro che si sta aggiornando.

2. eseguire tanzu mc credentials update. È possibile passare i valori alle seguenti opzioni di comando o lasciare che vengano richiesti dalla CLI:

   • --vsphere-user: nome dell'account vSphere.
   • --vsphere-password: Password dell'account vSphere.
   • --vsphere-thumbprint: Identificazione personale TLS dell'istanza di vCenter Server.

Aggiornamento delle credenziali solo per il cluster di gestione autonomo

Per aggiornare le credenziali vSphere di un cluster di gestione autonomo senza aggiornarle anche per i cluster del carico di lavoro, utilizzare il comando tanzu mc credentials update come indicato sopra, ma senza l'opzione --cascading.

Aggiornamento delle credenziali dei cluster del carico di lavoro

Per aggiornare le credenziali utilizzate da un singolo cluster del carico di lavoro per accedere a vSphere, utilizzare il comando tanzu cluster credentials update:

1. Eseguire tanzu context use MGMT-CLUSTER per accedere al cluster di gestione che ha creato il cluster del carico di lavoro che si sta aggiornando. Il cluster di gestione può essere il cluster supervisore o il cluster di gestione autonomo.

2. eseguire tanzu cluster credentials update CLUSTER-NAME. È possibile passare i valori alle seguenti opzioni di comando o lasciare che vengano richiesti dalla CLI:

   • --namespace: spazio dei nomi del cluster per cui si stanno aggiornando le credenziali, ad esempio default.
   • --vsphere-user: nome dell'account vSphere.
   • --vsphere-password: Password dell'account vSphere.
   • --vsphere-thumbprint: Identificazione personale TLS dell'istanza di vCenter Server.

È inoltre possibile utilizzare tanzu mc credentials update --cascading per aggiornare le credenziali vSphere per un cluster di gestione e tutti i cluster del carico di lavoro che gestisce.

AWS

Questa sezione non si applica alle distribuzioni AWS.

Azure

Aggiornamento delle credenziali del cluster di gestione autonomo e dei cluster del carico di lavoro

Importante

Prima di iniziare, ottenere le nuove credenziali di Azure dal portale di Azure o dall'amministratore di Azure.

Per aggiornare le credenziali di Azure utilizzate dal cluster di gestione autonomo corrente e da tutti i relativi cluster del carico di lavoro, utilizzare il comando tanzu mc credentials update --cascading:

1. Eseguire tanzu context use MGMT-CLUSTER per accedere al cluster del carico di lavoro che si sta aggiornando.

2. eseguire tanzu mc credentials update. È possibile passare i valori alle seguenti opzioni di comando o lasciare che vengano richiesti dalla CLI:

   • --azure-client-id: ID client dell'app per Tanzu Kubernetes Grid registrata in Azure.
   • --azure-client-secret: Segreto client dell'app per Tanzu Kubernetes Grid registrata in Azure.
   • --azure-tenant-id: L'ID tenant per Azure Active Directory in cui si trova l'app per Tanzu Kubernetes Grid.

Aggiornamento delle credenziali solo per il cluster di gestione autonomo

Per aggiornare le credenziali Azure di un cluster di gestione autonomo senza aggiornarle anche per i cluster del carico di lavoro, utilizzare il comando tanzu mc credentials update come indicato sopra, ma senza l'opzione --cascading.

Aggiornamento delle credenziali dei cluster del carico di lavoro

Per aggiornare le credenziali utilizzate da un singolo cluster del carico di lavoro per accedere ad Azure, utilizzare il comando tanzu cluster credentials update:

1. Eseguire tanzu context use MGMT-CLUSTER per accedere al cluster di gestione che ha creato il cluster del carico di lavoro che si sta aggiornando.

2. eseguire tanzu cluster credentials update CLUSTER-NAME. È possibile passare i valori alle seguenti opzioni di comando o lasciare che vengano richiesti dalla CLI:

   • --namespace: spazio dei nomi del cluster per cui si stanno aggiornando le credenziali, ad esempio default.
   • --azure-client-id: ID client dell'app per Tanzu Kubernetes Grid registrata in Azure.
   • --azure-client-secret: Segreto client dell'app per Tanzu Kubernetes Grid registrata in Azure.
   • --azure-tenant-id: L'ID tenant per Azure Active Directory in cui si trova l'app per Tanzu Kubernetes Grid.

È inoltre possibile utilizzare tanzu mc credentials update --cascading per aggiornare le credenziali di Azure per un cluster di gestione e tutti i cluster del carico di lavoro che gestisce.

Rinnovo automatico dei certificati dei nodi del piano di controllo

Configurare i cluster TKG per rinnovare automaticamente i certificati della macchina virtuale del nodo del piano di controllo come indicato di seguito, in base al metodo di configurazione e al tipo di cluster:

• Specifica oggetto di tipo Kubernetes (cluster basati sulla classe):

  • Nella specifica dell'oggetto Cluster includere il seguente blocco in spec.topology.variables:

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

• File di configurazione del cluster flat (cluster basati sulla classe o legacy):

  • Nel file di configurazione del cluster, includere le seguenti impostazioni:

    CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
    CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
    

Dove EXPIRY-DAYS è un'impostazione facoltativa che indica quanti giorni prima della data di scadenza del certificato rinnovare automaticamente i certificati del nodo del cluster. Valore predefinito: 90; minimo: 7.

Rinnovo dei certificati del cluster (cluster di gestione autonomo)

I cluster di gestione autonomi e i relativi cluster del carico di lavoro utilizzano certificati client per eseguire l'autenticazione delle richieste. Questi certificati sono validi per un anno. Per rinnovarli, è possibile aggiornare i cluster o eseguire la procedura seguente. Questa procedura è destinata ai certificati del cluster che non sono scaduti e sono ancora validi.

1. Identificare il cluster per cui si desidera rinnovare i propri certificati. Ad esempio:

   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
   

   Per elencare i nodi del cluster, eseguire:

   kubectl get nodes -o wide
   

2. Controllare la data di scadenza dei certificati:

   vSphere

   Eseguire il comando seguente.

   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

   Eseguire il comando seguente.

   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

   Eseguire il comando seguente.

   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;
   

   Output di esempio:

   ######
   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. Impostare il contesto di kubectl sul cluster di gestione. Ad esempio:

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

4. Ottenere il nome dell'oggetto KCP per il cluster di destinazione. Ad esempio:

   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. Rinnovare i certificati attivando un'implementazione del piano di controllo:

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

   Dopo aver eseguito questo comando, Tanzu Kubernetes Grid inizia a eseguire nuovamente il provisioning delle macchine 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. Quando tutte le macchine sono in stato Running, verificare che il rinnovo dei certificati sia stato completato correttamente:

   1. Impostare il contesto di kubectl sul cluster del carico di lavoro:

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

   2. Controllare nuovamente la data di scadenza dei certificati:

      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;
      

      Output di esempio:

      ######
      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
      

      Se il rinnovo dei certificati è stato completato correttamente, nella colonna Residual Time viene visualizzato 364d. I certificati nei nodi worker vengono rinnovati automaticamente.

Configurazione dei cluster con registri attendibili (supervisore)

Per configurare un cluster TKG distribuito da un supervisore in modo che utilizzi un registro di container privato esterno a TKG, ovvero un registro con un certificato autofirmato che non viene eseguito in un cluster TKG, vedere gli argomenti seguenti nella documentazione di vSphere:

• vSphere 8: Integrazione di un cluster TKG 2 con un registro di container privato
• vSphere 7: Utilizzo di un registro di container esterno con cluster Tanzu Kubernetes

Configurazione di cluster con più registri attendibili (cluster di gestione autonomo)

In un ambiente con limitazioni Internet con un cluster di gestione autonomo, è possibile configurare le variabili TKG_CUSTOM_IMAGE_REPOSITORY_* per consentire ai cluster TKG di accedere a un registro privato contenente immagini di sistema di TKG da cui eseguire il bootstrap, ad esempio una macchina virtuale Harbor come descritto in Distribuzione di un registro Harbor offline in vSphere.

Le variabili ADDITIONAL_IMAGE_REGISTRY_* configurano un nuovo cluster in modo che abbia comunicazioni attendibili con registri aggiuntivi che utilizzano certificati di autorità di certificazione (CA) autofirmati, ad esempio:

• Un registro privato che funge da repository dei pacchetti per l'installazione di pacchetti gestiti dalla CLI.
• Un registro Harbor scalabile autofirmato per le immagini delle app ospitate in TKG, distribuito con il pacchetto Harbor come descritto in Installazione di Harbor per il registro del servizio.
• Un registro immagini autofirmato per containerd come descritto in Configurazione del registro immagini nel repository containerd.

La modalità di configurazione dei cluster in modo che considerino attendibili questi registri privati aggiuntivi dipende dal fatto che il cluster sia basato sul piano o sulla classe, come descritto di seguito.

Registri attendibili per un cluster basato sulla classe

Per configurare un cluster del carico di lavoro basato sulla classe o un cluster di gestione autonomo con attendibilità per registri immagini personalizzati aggiuntivi, impostare le variabili come segue per un massimo di tre registri immagini aggiuntivi:

• Per configurare più di tre registri, configurare i primi tre come indicato di seguito nel passaggio 1 di un processo in due passaggi descritto in Creazione di un cluster basato sulla classe quindi seguire le istruzioni di Come fare in modo che un cluster basato sulla classe consideri attendibile un registro personalizzato di seguito per aggiungere altri registri al manifesto generato prima di creare il cluster nel passaggio 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"
  

  In cui OTHER-REGISTRY-<n> è l'indirizzo IP o il nome di dominio completo di un registro privato aggiuntivo e CA-BASE64-<n> è il certificato CA in formato codificato in base64, senza il prefisso http://. Questo è necessario perché il file verrà scritto su disco, quindi deve essere un nome di file Unix normale.

Registri attendibili per un nuovo cluster basato sul piano

Per consentire a un nuovo cluster TKC o basato sul piano di eseguire il pull di immagini dai registri dei container che utilizzano certificati autofirmati, aggiungere i certificati personalizzati ai nodi del cluster del carico di lavoro utilizzando un file di overlay ytt.

Il codice di overlay seguente aggiunge certificati CA personalizzati a tutti i nodi di un nuovo cluster. Il codice funziona in tutte le piattaforme di destinazione per i cluster basati su modelli di immagini di macchine virtuali Photon o Ubuntu.

Per gli overlay che personalizzano i cluster e creano un nuovo piano cluster, vedere Overlay ytt. Per informazioni su come scaricare e installare ytt, vedere Installazione degli strumenti Carvel.

1. Scegliere se applicare la CA personalizzata a tutti i nuovi cluster, solo a quelli creati in un'infrastruttura cloud o a quelli creati con una versione specifica del provider dell'API del cluster, come Provider di Cluster API vSphere v1.5.1.

2. Nella directory ~/.config/tanzu/tkg/providers/ locale, individuare la directory ytt che copre l'ambito scelto. Ad esempio /ytt/03_customizations/ si applica a tutti i cluster e /infrastructure-vsphere/ytt/ si applica a tutti i cluster vSphere.

3. Nella directory ytt scelta, creare un nuovo file .yaml oppure estendere un file di overlay esistente con il codice seguente:

   #@ 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. Nella stessa directory ytt, aggiungere l'autorità di certificazione a un file tkg-custom-ca.pem nuovo o esistente.

5. Prima di creare il cluster, impostare la funzionalità allow-legacy-cluster su true come descritto in (Legacy) Creazione di un cluster TKC o basato sul piano.

Aggiunta di attendibilità dei certificati CA personalizzati ai cluster esistenti (cluster di gestione autonomo)

È possibile abilitare la comunicazione attendibile tra un cluster esistente e altri registri Harbor personalizzati con certificati CA autofirmati, oltre a quella impostata dalle variabili di configurazione TKG_CUSTOM_IMAGE_REPOSITORY_*, per il TLS containerd e altri utilizzi. La modalità di esecuzione di questa operazione dipende dal fatto che il cluster sia basato sul piano o sulla classe, come descritto di seguito.

Come fare in modo che un cluster basato sulla classe consideri attendibile un registro personalizzato

Per aggiungere un registro personalizzato attendibile a un cluster basato sulla classe esistente, modificare il relativo oggetto Cluster e aggiungere le impostazioni di additionalImageRegistries in topology.variables nella specifica dell'oggetto:

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

In cui:

• OTHER-REGISTRY è la posizione del registro privato aggiuntivo, nel formato : . Ad esempio, 10.92.127.192:8443.
• CA-BASE64 è il certificato CA in formato codificato in base64, ad esempio LS0tLS1CRU[...].

Per aggiungere l'attendibilità per più registri, includere più blocchi di valore additionalImageRegistries.

Si tenga presente che i blocchi topology.variables per imageRepository e trust impostano i valori dalle variabili di configurazione TKG_CUSTOM_IMAGE_REPOSITORY_* e TKG_PROXY_CA_CERT.

Come fare in modo che un cluster basato sul piano consideri attendibile un registro personalizzato

Per abilitare l'attendibilità tra un cluster basato sul piano esistente e un registro Harbor con un certificato CA autofirmato:

1. Recuperare il certificato CA di Harbor:

   1. Passare al contesto del cluster che esegue Harbor, ad esempio un cluster di servizi condivisi:

      kubectl config use-context SERVICES-CLUSTER-CONTEXT
      

      Dove SERVICES-CLUSTER-CONTEXT è il contesto del cluster. Ad esempio, tkg-wld-admin@tkg-wld.

   2. Recuperare il certificato:

      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. Aggiungere l'autorità di certificazione personalizzata al kubeadmconfigtemplate del cluster di gestione autonomo:

   1. Passare al contesto del cluster di gestione.

      kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
      

      Dove MANAGEMENT-CLUSTER-CONTEXT è il contesto del cluster di gestione. Ad esempio, tkg-mgmt-admin@tkg-mgmt.

   2. In un editor, aprire il file del modello del cluster kubeadmconfigtemplate:

      kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
      

      Dove CLUSTER-NAME è il nome del cluster che deve essere modificato.

   3. Modificare la sezione spec.template.spec.files del file in modo che includa il certificato, come illustrato di seguito:

      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. Nella parte inferiore del file, aggiungere un blocco preKubeadmCommands come mostrato qui:

      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. Salvare il file del modello kubeadmconfigtemplate con le modifiche apportate.

4. Applicare al cluster di gestione autonomo una patch con le modifiche:

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

   L'esecuzione di questo comando attiva un aggiornamento in sequenza dei nodi del cluster e aggiorna la data e l'ora.

Configurazione dell'autenticazione in un registro di container privato

È possibile aggiungere segreti di autenticazione per consentire a un cluster di accedere a un registro di container privato che richiede l'autenticazione dell'utente per l'estrazione delle immagini. È inoltre possibile visualizzare, aggiornare o eliminare i segreti di autenticazione configurati per i registri privati a cui un cluster accede.

Aggiunta di un segreto di autenticazione per un registro di container privato

Utilizzando la CLI di Tanzu è possibile aggiungere segreti di autenticazione per accedere a un registro di container privato da un cluster. Dopo aver aggiunto il segreto del registro agli spazi dei nomi nel cluster, è possibile estrarre tutti i repository di pacchetti, i pacchetti e le immagini dei container ospitati nel registro privato. È quindi possibile aggiungere il repository dei pacchetti e le risorse dei pacchetti al cluster.

Prima di eseguire questa procedura, recuperare il nome utente e la password per il registro del container privato.

Per aggiungere un segreto di autenticazione a un registro privato eseguire il comando seguente:

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

In cui:

• SECRET-NAME è il nome del segreto di autenticazione del registro che si desidera aggiungere.
• NAMESPACE è lo spazio dei nomi di Tanzu Kubernetes Grid a cui il registro appartiene.
• USERNAME è il nome utente per accedere al registro. Racchiudere il nome utente tra virgolette singole se contiene caratteri speciali.

• PASSWORD è la password per accedere al registro. Racchiudere la password tra virgolette singole se contiene caratteri speciali. È inoltre possibile specificare la password nei formati seguenti:

  • Sostituire la stringa --password PASSWORD nel comando con --password-env-var ENV-VAR per specificare la password tramite la variabile di ambiente già configurata. Il formato del comando è il seguente:

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

  • Sostituire la stringa --password PASSWORD nel comando con la stringa --password-stdin per specificare la password tramite l'input standard e immettere la password quando richiesto. Il formato del comando è il seguente:

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

  • Sostituire la stringa --password PASSWORD nel comando con la stringa --password-file PASSWORD-FILE per specificare la password tramite un file di password. Il formato del comando è il seguente:

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

Facoltativamente, per rendere il segreto del registro disponibile in tutti gli spazi dei nomi in un cluster, utilizzare l'opzione --export-to-all-namespaces come illustrato nel formato seguente:

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

Il seguente è un output di esempio di questo comando:

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'

Visualizzazione dei segreti di autenticazione del registro in un cluster

È possibile visualizzare i segreti di autenticazione del registro nello spazio dei nomi predefinito o in tutti gli spazi dei nomi in un cluster. È possibile visualizzare i segreti sotto forma di tabella oppure di file JSON o YAML.

Per visualizzare i segreti di autenticazione del registro in uno spazio dei nomi specifico in un cluster, eseguire quanto segue:

tanzu secret registry list -n NAMESPACE

In cui NAMESPACE è lo spazio dei nomi di Tanzu Kubernetes Grid a cui il registro appartiene.

Il seguente è un esempio di questo comando:

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

Per visualizzare l'elenco dei segreti di autenticazione del registro in tutti gli spazi dei nomi in un cluster, eseguire quanto segue:

tanzu secret registry list -A

Il seguente è un esempio di questo comando:

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

Per visualizzare l'elenco dei segreti di autenticazione del registro nel formato di file JSON, eseguire il comando seguente:

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

Il seguente è un esempio di questo comando:

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"
 }
]

Per visualizzare l'elenco dei segreti di autenticazione del registro nel formato di file YAML, eseguire quanto segue:

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

Il seguente è un esempio di questo comando:

 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

Per visualizzare l'elenco dei segreti di autenticazione del registro in formato di tabella, eseguire quanto segue:

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

Il seguente è un esempio di questo comando:

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

Aggiornamento di un segreto di autenticazione del registro

È possibile aggiornare le credenziali in un segreto e renderlo disponibile in tutti gli spazi dei nomi o solo in uno spazio dei nomi nel cluster.

Per aggiornare il segreto nello spazio dei nomi in cui è stato creato, eseguire il comando seguente:

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

In cui:

• SECRET-NAME è il nome del segreto del registro che si desidera aggiornare.
• NAMESPACE è lo spazio dei nomi di Tanzu Kubernetes Grid in cui si sta aggiornando il segreto di autenticazione del registro.
• USERNAME è il nuovo nome utente per accedere al registro (se si desidera aggiornare il nome utente).
• PASSWORD è la nuova password per il registro (se si desidera aggiornare la password).

Nota

è possibile aggiornare il nome utente o la password oppure entrambi.

Il seguente è un esempio di questo comando:

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'

Per aggiornare il segreto di autenticazione del registro e renderlo disponibile negli altri spazi dei nomi nel cluster, eseguire il comando seguente:

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

In cui:

• SECRET-NAME è il nome del segreto del registro che si desidera aggiornare.
• NAMESPACE è lo spazio dei nomi di Tanzu Kubernetes Grid in cui si sta aggiornando il segreto di autenticazione del registro.
• USERNAME è il nome utente per accedere al registro. Immettere un nuovo nome utente se si desidera aggiornare il nome utente.
• PASSWORD è la password per il registro. Immettere una nuova password se si desidera aggiornare la password.

Il seguente è un esempio di questo comando:

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

Per rendere un segreto di autenticazione del registro non disponibile negli altri spazi dei nomi nel cluster, eseguire il comando seguente:

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

In cui:

• SECRET-NAME è il nome del segreto del registro che si desidera aggiornare.
• NAMESPACE è lo spazio dei nomi di Tanzu Kubernetes Grid in cui si sta aggiornando il segreto di autenticazione del registro.
• USERNAME è il nome utente per accedere al registro.
• PASSWORD è la password per il registro.

Il seguente è un esempio di questo comando:

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

Eliminazione di un segreto di autenticazione del registro

Utilizzando la CLI di Tanzu, è possibile eliminare un segreto di autenticazione del registro in un cluster. Per eliminare un segreto di autenticazione del registro in uno spazio dei nomi specifico, eseguire il comando seguente:

tanzu secret registry delete SECRET-NAME -n NAMESPACE

In cui:

• SECRET-NAME è il nome del segreto del registro che si desidera eliminare.
• (Facoltativo) NAMESPACE è lo spazio dei nomi di Tanzu Kubernetes Grid da cui si desidera eliminare il segreto di autenticazione del registro. Se non si specifica uno spazio dei nomi, il segreto di autenticazione viene eliminato dallo spazio dei nomi predefinito. Se il segreto è stato esportato in altri spazi dei nomi nel cluster, viene eliminato anche da tali spazi dei nomi.

Il seguente è un esempio di questo comando:

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'