Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment alterner l'autorité de certification racine utilisée pour la validation des packages dans l'appliance Google Distributed Cloud (GDC) isolée.
La validation des packages GDC utilise une autorité de certification racine pour valider les certificats de clé de version. Il est donc essentiel de remplacer régulièrement le certificat de l'autorité de certification racine. Vous devez faire tourner l'autorité de certification racine si vous y êtes invité dans un avis de version ou dans le message d'avertissement qui peut s'afficher lors d'une mise à niveau.
Avant de commencer
Pour alterner le certificat de validation des packages, vous devez disposer des rôles d'identité et d'accès nécessaires :
Assurez-vous de disposer d'un accès en écriture à package-validation-root-certs ConfigMap.
Demandez à votre Administrateur de sécurité de vous attribuer le rôle Débogueur de mise à niveau (upgrade-debugger-cp).
La vérification de la rotation du certificat est obligatoire
Avant d'effectuer l'opération, vérifiez si une rotation du certificat de validation du package est requise :
Définissez la variable d'environnement KUBECONFIG :
$KUBECONFIG=PATH_TO_KUBECONFIG_FILE
Remplacez PATH_TO_KUBECONFIG_FILE par le chemin d'accès au fichier kubeconfig que vous avez obtenu en exécutant gdcloud auth login dans le cluster d'administrateur racine.
Déterminez si une mise à niveau est requise en comparant l'ancrage de confiance actuel au dernier ancrage de confiance. Les données ConfigMap à harbor-system/package-validation-root-certs sont comparées à l'autorité de certification locale :
Effectuer la rotation du certificat et la mise à niveau sur l'appliance
Pour faire pivoter l'objet ConfigMap situé à harbor-system/package-validation-root-certs dans le cluster d'administrateur racine, procédez comme suit. L'opérateur d'infrastructure a besoin d'un accès en écriture à ConfigMap.
Créez les variables suivantes et attribuez-leur des valeurs :
Cela permet de faire tourner un nouveau certificat dans package-validation-root-cert.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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`."]]