Cette page a été traduite par l'API Cloud Translation.

Alterner le certificat de validation du package

Cette page explique comment alterner l'autorité de certification racine utilisée pour la validation des packages dans Google Distributed Cloud (GDC) air-gapped.

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. Pour en savoir plus sur la procédure de mise à niveau, consultez Transférer les artefacts vers le registre de conteneurs.

Avant de commencer

Pour faire pivoter le certificat de validation des packages, vous devez disposer des rôles d'identité et d'accès nécessaires :

Débogueur System Artifact Registry : dispose d'un accès en lecture et en écriture à toutes les ressources Harbor. Demandez à votre administrateur de sécurité de vous accorder le rôle de cluster "Débogueur System Artifact Registry" (sar-debugger).

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 :

$ CURRENT_TRUST_ANCHOR=$(kubectl  --kubeconfig=$KUBECONFIG get cm package-validation-root-certs -n harbor-system -o jsonpath='{.data.ca\.crt}')

$ LATEST_TRUST_ANCHOR=$(cat /root/release/staging_root_ca_certificate.crt)

$ diff <( echo "$CURRENT_TRUST_ANCHOR" ) <( echo "$LATEST_TRUST_ANCHOR" ) && echo trust anchors are same  || echo trust anchors are different, upgrade required!

Si le certificat doit être renouvelé, consultez Effectuer la rotation et la mise à niveau du certificat.

Effectuer la rotation et la mise à niveau des certificats

Utilisez les outils et processus Infrastructure as Code (IaC) pour faire pivoter l'objet ConfigMap situé à harbor-system/package-validation-root-certs dans le cluster d'administrateur racine.

Créez les variables suivantes et attribuez-leur des valeurs :

USERNAME=gitlab-admin
URL=GDC_URL
TEMPLATE_FILE="/tmp/package-validation-root-certs.yaml.tpl"
TARGET_FOLDER=/tmp/${USERNAME}/infrastructure/zonal/zones/ZONE_NAME/root-admin/package-validation
OUTPUT="${TARGET_FOLDER}/package-validation-root-certs.yaml"
LATEST_TRUST_ANCHOR_CA_FILE=/root/release/staging_root_ca_certificate.crt
CONFIGMAP_NAME=package-validation-root-certs
NAMESPACE=harbor-system

Remplacez GDC_URL par l'URL de votre projet GDC.

Clonez le dépôt :
```
git -c http.sslVerify=false clone -b main https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac /tmp/${USERNAME}
```
Remplacez TOKEN par votre jeton d'accès personnel GitLab. Pour savoir comment créer un jeton d'accès personnel, consultez https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.
Créez le dossier cible qui contiendra les fichiers de sortie du processus de rotation des certificats :
```
mkdir -p "${TARGET_FOLDER}"
```

Mettez à jour et remplacez la valeur de LATEST_TRUST_ANCHOR :

  cat <<EOF  > "${OUTPUT}"
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: ${CONFIGMAP_NAME}
    namespace: ${NAMESPACE}
  data:
    ca.crt: |
  $(sed 's/^/    /' "${LATEST_TRUST_ANCHOR_CA_FILE}")
  EOF

Vérifiez que l'ancrage de confiance a été correctement mis à jour :

$ cat "${OUTPUT}"
apiVersion: v1
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    MIID3DCCAsSgAwIBAgITb1SPkse7G8syTQUFfc8NOqY4RzANBgkqhkiG9w0BAQsF
    ADB2MQswCQYDVQQGEwJ1czETMBEGA1UECBMKY2FsaWZvcm5pYTETMBEGA1UEBxMK
    c3Vubnl2aWxsZTEPMA0GA1UEChMGZ29vZ2xlMQ0wCwYDVQQLEwRnZGNoMR0wGwYD
    VQQDExRnZGNoLWNvZGUtc2lnbmluZy1jYTAeFw0yMzAzMDUwNjMyMjlaFw0zMzAz
    MDIwNjMyMjhaMHYxCzAJBgNVBAYTAnVzMRMwEQYDVQQIEwpjYWxpZm9ybmlhMRMw
    EQYDVQQHEwpzdW5ueXZpbGxlMQ8wDQYDVQQKEwZnb29nbGUxDTALBgNVBAsTBGdk
    Y2gxHTAbBgNVBAMTFGdkY2gtY29kZS1zaWduaW5nLWNhMIIBIjANBgkqhkiG9w0B
    AQEFAAOCAQ8AMIIBCgKCAQEAsD2XLR9cxbP0dnJfqdiBr1ZX1oq3AklU0IG5p7ZL
    F7NA1/qoKDWe5RuoBM/X4snI/5gnz9zuHapXA9HLN7bfEpr7orXlK00jn2AGqiNk
    jBriDFqgOF33W+/AWDG8HujlMosYK+Gp4FU9ni5S2Ay2sMk83CC+eFh7T//ji8y9
    PnUsLEwmNiCDb1UMqrcAXpmeTxd7PZlPIsujrkqLGAwjEE02XA7SqMPe/cPfzKEO
    0mK1VvxYmHdLOJtyKWgYIwy6+8Ka6Js3WgjNi0fLnxH7kbVaIvbLSvZa00JsX4GQ
    v1bxLSRUvfuI66O/vOEWH3zzKReTjQKMflz4570gciAntQIDAQABo2MwYTAOBgNV
    HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUWZ0gQZKNybd8
    BAy2gamLf7Isiq4wHwYDVR0jBBgwFoAUWZ0gQZKNybd8BAy2gamLf7Isiq4wDQYJ
    KoZIhvcNAQELBQADggEBAGtifprappLxMaPQxGS8v2DYSlF3OYcBw2+JWISR62vB
    7mRjhuwh6QmcDHxLu+9RQ7E6aNaADCKbw0/6/OtGhvaxNtmZuBaBRhYPf2juQSgW
    BtQbmdr3h99wAFtpfvt4FOFYvTMRByOm/imi8Oq1+1y3OQEp2ayiMZ9pBg8DDY59
    juuszBKNZA99cMTtAQPCFkbMODRGFDYlaM5JhxVJ8/J9TCh4tNLx1BTJUtaZYjVF
    TlkzFdCoUnHWFPsapL1Mhje1vZBrhVKkSQETBfssvWQSNamOOLL139O428pxUUrH
    a7ahVae1mO4kQce3uBp3WyKcBx3pPNmYbRtGCe2xSB0=
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: package-validation-root-certs
  namespace: harbor-system

Supprimez le fichier temporaire utilisé pour remplacer la valeur de l'ancrage de confiance :
```
$ rm "${TEMPLATE_FILE}" "${AWK_RULE_FILE}" "${LATEST_TRUST_ANCHOR_CA_FILE}"
```

Validez l'objet avant de valider la modification :

$ /root/release/gdcloud system assets validate --config "${OUTPUT}" --level object

Effectuez un commit sur la modification :

$ cd "${TARGET_FOLDER}"
$ git add -A
$ git config user.name "GitlabAdmin"
$ git config user.email "gitlab-admin@example.com"

$ git commit -am "upgrade package-validation-root-certs"
$ git checkout -b ${USERNAME}-branch

Créez la demande de fusion :

$ git -c http.sslVerify=false push -o merge_request.create \
https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac ${USERNAME}-branch

Le résultat doit ressembler à l'exemple suivant :

warning: redirecting to https://gitlab.zone1.google.gdch.test/gdch/iac.git/
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 16 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (7/7), 920 bytes | 920.00 KiB/s, done.
Total 7 (delta 0), reused 0 (delta 0)
remote:
remote: View merge request for gitlab-admin-branch:
remote:   https://gitlab.GDC_URL/gdch/iac/-/merge_requests/1
remote:
To https://gitlab.zone1.google.gdch.test/gdch/iac
* [new branch]      gitlab-admin-branch -> gitlab-admin-branch

Une fois votre modification fusionnée, vous devez obtenir l'approbation de la rotation des certificats auprès d'un autre IO.

Obtenir l'approbation pour la rotation du certificat

Un autre utilisateur d'IO doit assumer le rôle d'approbateur et valider cette modification. L'IO approbateur doit suivre les étapes suivantes :

Téléchargez l'ancre de confiance protégée de la version de mise à niveau cible sur la clé USB. Pour télécharger ce fichier, vous devez avoir accès au bucket Cloud Storage. Pour y accéder, contactez l'assistance GDC. Pour en savoir plus sur le téléchargement des distributions et des fichiers GDC, consultez Télécharger des fichiers.
Copiez l'ancrage de confiance de la version à jour dans l'environnement isolé à l'aide de la clé USB.
Récupérez le certificat et comparez-le à celui de la demande de fusion :
```
VERSION=VERSION
DIGEST=DIGEST_INFORMATION
export GCS_BUCKET=private-cloud-release
DOWNLOADER=gdch-downloader-root-ca-$VERSION.sh
gcloud storage cp "gs://$GCS_BUCKET/$VERSION/$DOWNLOADER" .
echo "$DIGEST $DOWNLOADER" | sha256sum -c && chmod +x $DOWNLOADER && ./$DOWNLOADER --skip-unzip
$ cat root_ca_certificate.crt
```
Remplacez les éléments suivants :
- VERSION : version de la version GDC. Exemple :1.x.y-gdch.z
- DIGEST_INFORMATION : informations sur le condensé que vous avez reçues de votre point de contact Google. Les informations sur le résumé varient en fonction de la version. Par exemple, le récapitulatif 1.2.0-gdch.243 est différent du récapitulatif 1.2.0-gdch.321. Ces informations sont fournies manuellement pour des raisons de sécurité.

Approuvez la modification lorsque les données du certificat ca.crt sont identiques à celles du certificat téléchargé. Le certificat doit ressembler à l'exemple suivant :

Vérifiez si l'opération a réussi en consultant la ressource RootSync. Une ressource RootSync peut être utilisée pour gérer toutes les ressources du cluster disposant d'autorisations cluster-admin. Vérifiez si la ressource RootSync a bien été affichée :
```
$ kubectl --kubeconfig=$KUBECONFIG describe rootsync/root-sync -n config-management-system
```
Si le rendu RootSync a réussi, le message Rendering succeeded s'affiche dans le résultat.
Si l'opération a échoué, le problème est probablement dû à un problème de configuration IaC. Pour en savoir plus, consultez Conseils de débogage pour atténuer les problèmes courants liés à l'IaC.

Alterner le certificat de validation du package Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

La vérification de la rotation du certificat est obligatoire

Effectuer la rotation et la mise à niveau des certificats

Obtenir l'approbation pour la rotation du certificat

Alterner le certificat de validation du package