Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menjelaskan cara mengganti otoritas sertifikat root yang digunakan untuk validasi paket di perlengkapan air-gapped Google Distributed Cloud (GDC)
Validasi paket GDC menggunakan otoritas sertifikat root (CA) untuk memvalidasi sertifikat kunci rilis. Oleh karena itu, sertifikat CA root harus dirotasi secara berkala. Anda harus merotasi CA root jika Anda
diinstruksikan untuk melakukannya melalui catatan rilis atau pesan peringatan yang mungkin
ditampilkan saat Anda melakukan upgrade.
Sebelum memulai
Untuk mengganti sertifikat validasi paket, Anda harus memiliki peran identitas dan akses yang diperlukan:
Pastikan Anda memiliki akses tulis ke package-validation-root-certs ConfigMap.
Minta Admin Keamanan Anda untuk memberi Anda peran Upgrade Debugger (upgrade-debugger-cp).
Verifikasi rotasi sertifikat diperlukan
Verifikasi apakah rotasi sertifikat validasi paket diperlukan sebelum
melakukan operasi:
Tetapkan variabel lingkungan KUBECONFIG:
$KUBECONFIG=PATH_TO_KUBECONFIG_FILE
Ganti PATH_TO_KUBECONFIG_FILE dengan jalur ke file
kubeconfig yang Anda dapatkan dengan
menjalankan gdcloud auth login di cluster admin root.
Tentukan apakah upgrade diperlukan dengan membandingkan trust anchor saat ini dengan trust anchor terbaru. Data ConfigMap di harbor-system/package-validation-root-certs
dibandingkan dengan trust anchor lokal:
Melakukan rotasi dan upgrade sertifikat di appliance
Lakukan langkah-langkah berikut untuk memutar objek ConfigMap yang berada di
harbor-system/package-validation-root-certs di cluster admin root. Operator Infrastruktur memerlukan akses tulis ke ConfigMap.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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`."]]