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 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 :

$ 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!

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 :

USERNAME=USER_NAME #IO
TARGET_FOLDER=/tmp/${USERNAME}
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 USER_NAME par le nom d'utilisateur IO.

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

Appliquez la nouvelle configuration avec kubectl :
```
  kubectl apply -f ${OUTPUT}
```
Assurez-vous que le fichier ca.crt nouvellement appliqué est présent dans ConfigMap :
```
  kubectl describe configmap package-validation-root-certs -n harbor-system
```

Cela permet de faire tourner un nouveau certificat dans package-validation-root-cert.