Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina descrive come ruotare l'autorità di certificazione radice utilizzata per
la convalida dei pacchetti nell'appliance isolata di Google Distributed Cloud (GDC)
La convalida del pacchetto GDC utilizza un'autorità di certificazione (CA) radice per convalidare i certificati delle chiavi di rilascio. Per questo motivo è fondamentale
ruotare periodicamente il certificato CA radice. Devi ruotare la CA radice se
ti viene chiesto di farlo tramite un avviso di rilascio o il messaggio di avviso che potrebbe
essere visualizzato durante l'esecuzione di un upgrade.
Prima di iniziare
Per ruotare il certificato di convalida del pacchetto, devi disporre dei ruoli di identità e accesso necessari:
Assicurati di disporre dell'accesso in scrittura a package-validation-root-certs ConfigMap.
Chiedi all'Amministratore sicurezza di concederti il ruolo Esegui upgrade di Debugger (upgrade-debugger-cp).
Verifica della rotazione del certificato obbligatoria
Verifica che sia necessaria la rotazione di un certificato di convalida del pacchetto prima di
eseguire l'operazione:
Imposta la variabile di ambiente KUBECONFIG:
$KUBECONFIG=PATH_TO_KUBECONFIG_FILE
Sostituisci PATH_TO_KUBECONFIG_FILE con il percorso del
file kubeconfig che hai ottenuto eseguendo
gdcloud auth login nel cluster di amministrazione principale.
Determina se è necessario un upgrade confrontando il trust anchor attuale con l'ultimo trust anchor. I dati ConfigMap in harbor-system/package-validation-root-certs
vengono confrontati con il trust anchor locale:
Eseguire la rotazione dei certificati e l'upgrade sull'appliance
Per ruotare l'oggetto ConfigMap che si trova in
harbor-system/package-validation-root-certs nel cluster di amministrazione principale, segui questi passaggi. L'operatore
dell'infrastruttura deve disporre dell'accesso in scrittura a ConfigMap.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 UTC."],[],[],null,["# Rotate package validation certificate\n\nThis page describes how to rotate the root certificate authority used for\npackage validation in Google Distributed Cloud (GDC) air-gapped appliance\n\nGDC package validation uses a root certificate\nauthority (CA) to validate release key certificates. This makes it critical to\nrotate the root CA certificate periodically. You must rotate the root CA if you\nare instructed to do so through a release notice or the warning message that may\nbe displayed as you perform an upgrade.\n\nBefore you begin\n----------------\n\nTo rotate the package validation certificate, you must have the necessary\nidentity and access roles:\n\n- Ensure that you have write access to `package-validation-root-certs ConfigMap`.\n- Ask your Security Admin to grant you the Upgrade Debugger (`upgrade-debugger-cp`) role.\n\nVerify certificate rotation is required\n---------------------------------------\n\nVerify a package validation certificate rotation is required before\nperforming the operation:\n\n1. Set the `KUBECONFIG` environment variable:\n\n $ KUBECONFIG=\u003cvar translate=\"no\"\u003ePATH_TO_KUBECONFIG_FILE\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003ePATH_TO_KUBECONFIG_FILE\u003c/var\u003e with the path to the\n [`kubeconfig` file that you obtained](/distributed-cloud/hosted/docs/latest/appliance/resources/gdcloud-auth) by\n running `gdcloud auth login` in the root admin cluster.\n2. Determine if an upgrade is required by comparing the current trust anchor to the\n latest trust anchor. The `ConfigMap` data at `harbor-system/package-validation-root-certs`\n is compared against the local trust anchor:\n\n $ CURRENT_TRUST_ANCHOR=$(kubectl --kubeconfig=$KUBECONFIG get cm package-validation-root-certs -n harbor-system -o jsonpath='{.data.ca\\.crt}')\n\n $ LATEST_TRUST_ANCHOR=$(cat /root/release/staging_root_ca_certificate.crt)\n\n $ diff \u003c( echo \"$CURRENT_TRUST_ANCHOR\" ) \u003c( echo \"$LATEST_TRUST_ANCHOR\" ) && echo trust anchors are same || echo trust anchors are different, upgrade required!\n\nPerform certificate rotation and upgrade on the appliance\n---------------------------------------------------------\n\nPerform the following steps to rotate the `ConfigMap` object located at\n`harbor-system/package-validation-root-certs` in the root admin cluster. The\nInfrastructure Operator needs write access to the `ConfigMap`.\n\n1. Create and assign values to the following variables:\n\n USERNAME=\u003cvar translate=\"no\"\u003eUSER_NAME\u003c/var\u003e #IO\n TARGET_FOLDER=/tmp/${USERNAME}\n OUTPUT=\"${TARGET_FOLDER}/package-validation-root-certs.yaml\"\n LATEST_TRUST_ANCHOR_CA_FILE=/root/release/staging_root_ca_certificate.crt\n CONFIGMAP_NAME=package-validation-root-certs\n NAMESPACE=harbor-system\n\n Replace \u003cvar translate=\"no\"\u003eUSER_NAME\u003c/var\u003e with the IO username.\n2. Create the target folder that will contain the output files from the certificate rotation process:\n\n mkdir -p \"${TARGET_FOLDER}\"\n\n3. Update and replace the value of `LATEST_TRUST_ANCHOR`:\n\n cat \u003c\u003cEOF \u003e \"${OUTPUT}\"\n apiVersion: v1\n kind: ConfigMap\n metadata:\n name: ${CONFIGMAP_NAME}\n namespace: ${NAMESPACE}\n data:\n ca.crt: |\n $(sed 's/^/ /' \"${LATEST_TRUST_ANCHOR_CA_FILE}\")\n EOF\n\n4. Apply the new configuration with `kubectl`:\n\n kubectl apply -f ${OUTPUT}\n\n5. Ensure that the newly applied ca.crt is present within the `ConfigMap`:\n\n kubectl describe configmap package-validation-root-certs -n harbor-system\n\nThis takes care of rotating a new certificate in the `package-validation-root-cert`."]]