Ruota il certificato di convalida del pacchetto

Questa pagina descrive come ruotare l'autorità di certificazione radice utilizzata per la convalida dei pacchetti in Google Distributed Cloud (GDC) air-gapped

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. Per ulteriori informazioni sulla procedura di upgrade, consulta Eseguire il push degli artefatti nel registro dei container.

Prima di iniziare

Per ruotare il certificato di convalida del pacchetto, devi disporre dei ruoli di identità e accesso necessari:

  • Debugger del registro degli artefatti di sistema: ha accesso in lettura e scrittura a tutte le risorse Harbor. Chiedi all'Amministratore sicurezza di concederti il ruolo cluster System Artifact Registry Debugger (sar-debugger).

Verifica della rotazione del certificato obbligatoria

Verifica che sia necessaria la rotazione di un certificato di convalida del pacchetto prima di eseguire l'operazione:

  1. 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.

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

    $ 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!
    
  3. Se è necessario eseguire la rotazione del certificato, consulta Eseguire la rotazione e l'upgrade del certificato.

Eseguire la rotazione e l'upgrade del certificato

Utilizza strumenti e processi Infrastructure as Code (IaC) per ruotare l'oggetto ConfigMap che si trova in harbor-system/package-validation-root-certs nel cluster di amministrazione principale.

  1. Crea e assegna valori alle seguenti variabili:

    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
    

    Sostituisci GDC_URL con l'URL del tuo progetto GDC.

  2. Clona il repository:

    git -c http.sslVerify=false clone -b main https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac /tmp/${USERNAME}
    

    Sostituisci TOKEN con il tuo token di accesso personale di GitLab. Per saperne di più, consulta la pagina su come creare un token di accesso personale all'indirizzo https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.

  3. Crea la cartella di destinazione che conterrà i file di output del processo di rotazione dei certificati:

    mkdir -p "${TARGET_FOLDER}"
    
  4. Aggiorna e sostituisci il valore di 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
    
  5. Verifica che l'ancora di attendibilità sia stata aggiornata correttamente:

    $ 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
    
  6. Rimuovi il file temporaneo utilizzato per sostituire il valore dell'ancora di attendibilità:

    $ rm "${TEMPLATE_FILE}" "${AWK_RULE_FILE}" "${LATEST_TRUST_ANCHOR_CA_FILE}"
    
  7. Convalida l'oggetto prima di eseguire il commit della modifica:

    $ /root/release/gdcloud system assets validate --config "${OUTPUT}" --level object
    
  8. Esegui il commit della modifica:

    $ 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
    
  9. Crea la richiesta di unione:

    $ git -c http.sslVerify=false push -o merge_request.create \
    https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac ${USERNAME}-branch
    
  10. L'output deve essere simile al seguente esempio:

    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
    
  11. Una volta unita la modifica, devi ottenere l'approvazione per la rotazione del certificato da un altro IO.

Ottenere l'approvazione per la rotazione del certificato

Un altro utente IO deve assumere il ruolo di approvatore e verificare questa modifica. L'IO che approva deve procedere come segue:

  1. Scarica il trust anchor protetto della versione di upgrade di destinazione sull'unità USB. Per scaricare questo file, devi avere accesso al bucket Cloud Storage. Per ottenere l'accesso, riassegna la richiesta all'assistenza GDC. Per maggiori informazioni sul download di distribuzioni e file GDC, vedi Scaricare file.

  2. Copia l'ancora di attendibilità della versione aggiornata nell'ambiente isolato utilizzando l'unità USB.

  3. Recupera il certificato e confrontalo con quello nella richiesta di unione:

    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
    

    Sostituisci quanto segue:

    • VERSION: la versione di rilascio di GDC. Ad esempio, 1.x.y-gdch.z.
    • DIGEST_INFORMATION: le informazioni del riepilogo che hai ricevuto dal tuo punto di contatto Google. Le informazioni del riepilogo variano a seconda della release specifica. Ad esempio, il riepilogo 1.2.0-gdch.243 è diverso dal riepilogo 1.2.0-gdch.321. Queste informazioni vengono fornite manualmente per motivi di sicurezza.
  4. Approva la modifica quando i dati del certificato ca.crt sono uguali a quelli del certificato scaricato. Il certificato deve essere simile all'esempio seguente:

    -----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-----
    
  5. Verifica se l'operazione è riuscita controllando la risorsa RootSync. Una risorsa RootSync può essere utilizzata per gestire qualsiasi risorsa sul cluster che disponga delle autorizzazioni cluster-admin. Controlla se il rendering della risorsa RootSync è stato eseguito correttamente:

    $ kubectl --kubeconfig=$KUBECONFIG describe rootsync/root-sync -n config-management-system
    
  6. Se il rendering di RootSync è andato a buon fine, l'output includerà il messaggio: Rendering succeeded.

  7. Se l'operazione non è riuscita, il problema è probabilmente dovuto a un problema di configurazione IaC. Per saperne di più, consulta i suggerimenti per il debug per mitigare i problemi comuni di IaC.