This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

Gestione dei segreti del cluster

Updated on   11/16/2023

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:

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.

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.


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.26.8+vmware.1 <none> prod v1.26.8---vmware.2-tkg.1

    Per elencare i nodi del cluster, eseguire:

    kubectl get nodes -o wide
  2. Controllare la data di scadenza dei certificati:

    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;

    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.26.8+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.26.8+vmware.1 workload-slot35rp10-control-plane-ggsmj workload-slot35rp10 workload-slot35rp10-control-plane-ggsmj vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f Running 42h v1.26.8+vmware.1 workload-slot35rp10-control-plane-hxbxb workload-slot35rp10 workload-slot35rp10-control-plane-hxbxb vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd Running 42h v1.26.8+vmware.1 workload-slot35rp10-control-plane-sm4nw workload-slot35rp10 workload-slot35rp10-control-plane-sm4nw vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce Running 42h v1.26.8+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.26.8+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:

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:

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.7.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'
check-circle-line exclamation-circle-line Translation Error Open MyLibrary close-line
Scroll to top icon
Send Feedback Send Feedback