Zertifikat für die Paketvalidierung rotieren

Auf dieser Seite wird beschrieben, wie Sie die Stammzertifizierungsstelle rotieren, die für die Paketvalidierung in Google Distributed Cloud (GDC) Air-Gapped verwendet wird.

Bei der Validierung von GDC-Paketen wird eine Stammzertifizierungsstelle (CA) verwendet, um Release-Schlüsselzertifikate zu validieren. Daher ist es wichtig, das Root-CA-Zertifikat regelmäßig zu rotieren. Sie müssen die Stammzertifizierungsstelle rotieren, wenn Sie durch eine Release-Mitteilung oder die Warnmeldung, die möglicherweise während eines Upgrades angezeigt wird, dazu aufgefordert werden. Weitere Informationen zum Upgrade finden Sie unter Artefakte in die Container Registry übertragen.

Hinweise

Zum Rotieren des Zertifikats für die Paketvalidierung benötigen Sie die erforderlichen Identitäts- und Zugriffsrollen:

  • System Artifact Registry Debugger: hat Lese- und Schreibzugriff auf alle Harbor-Ressourcen. Bitten Sie Ihren Sicherheitsadministrator, Ihnen die Clusterrolle „System Artifact Registry Debugger“ (sar-debugger) zuzuweisen.

Prüfen, ob eine Zertifikatrotation erforderlich ist

Prüfen Sie, ob eine Rotation des Zertifikats zur Paketvalidierung erforderlich ist, bevor Sie den Vorgang ausführen:

  1. Legen Sie die Umgebungsvariable KUBECONFIG fest:

    $ KUBECONFIG=PATH_TO_KUBECONFIG_FILE
    

    Ersetzen Sie PATH_TO_KUBECONFIG_FILE durch den Pfad zur Datei kubeconfig, die Sie durch Ausführen von gdcloud auth login im Administratorcluster des Stammclusters erhalten haben.

  2. Prüfen Sie, ob ein Upgrade erforderlich ist, indem Sie den aktuellen Vertrauensanker mit dem neuesten Vertrauensanker vergleichen. Die ConfigMap-Daten unter harbor-system/package-validation-root-certs werden mit dem lokalen Trust-Anchor verglichen:

    $ 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. Wenn das Zertifikat rotiert werden muss, lesen Sie den Abschnitt Zertifikatsrotation und Upgrade durchführen.

Zertifikatsrotation und ‑upgrade durchführen

Verwenden Sie IaC-Tools (Infrastructure as Code) und -Prozesse, um das ConfigMap-Objekt unter harbor-system/package-validation-root-certs im Administratorstammcluster zu rotieren.

  1. Erstellen Sie die folgenden Variablen und weisen Sie ihnen Werte zu:

    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
    

    Ersetzen Sie GDC_URL durch die URL Ihres GDC-Projekts.

  2. Klonen Sie das Repository:

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

    Ersetzen Sie TOKEN durch Ihr persönliches Zugriffstoken von GitLab. Weitere Informationen finden Sie unter https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.

  3. Erstellen Sie den Zielordner, der die Ausgabedateien aus dem Zertifikatsrotationsprozess enthält:

    mkdir -p "${TARGET_FOLDER}"
    
  4. Aktualisieren und ersetzen Sie den Wert von 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. Prüfen Sie, ob der Trust-Anker korrekt aktualisiert wurde:

    $ 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. Entfernen Sie die temporäre Datei, die zum Ersetzen des Werts des Vertrauensankers verwendet wurde:

    $ rm "${TEMPLATE_FILE}" "${AWK_RULE_FILE}" "${LATEST_TRUST_ANCHOR_CA_FILE}"
    
  7. Validieren Sie das Objekt, bevor Sie die Änderung übernehmen:

    $ /root/release/gdcloud system assets validate --config "${OUTPUT}" --level object
    
  8. Führen Sie einen Commit für die Änderung durch:

    $ 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. Zusammenführungsanfrage erstellen:

    $ git -c http.sslVerify=false push -o merge_request.create \
    https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac ${USERNAME}-branch
    
  10. Ihre Ausgabe muss wie im folgenden Beispiel aussehen:

    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. Sobald Ihre Änderung zusammengeführt wurde, müssen Sie von einem anderen IO die Genehmigung für die Zertifikatsrotation einholen.

Genehmigung für die Zertifikatrotation einholen

Ein anderer IO-Nutzer muss die Rolle des Genehmigers übernehmen und diese Änderung bestätigen. So genehmigen Sie eine IO:

  1. Laden Sie den geschützten Trust-Anchor der Ziel-Upgradeversion auf den USB-Speicher. Zum Herunterladen dieser Datei benötigen Sie Zugriff auf den Cloud Storage-Bucket. Um Zugriff zu erhalten, wenden Sie sich an den GDC-Support. Weitere Informationen zum Herunterladen von GDC-Distributionen und -Dateien finden Sie unter Dateien herunterladen.

  2. Kopieren Sie den Trust-Anker der aktuellen Version mit dem USB-Laufwerk in die Air-Gap-Umgebung.

  3. Rufen Sie das Zertifikat ab und vergleichen Sie das Zertifikat in der Merge-Anfrage mit dem abgerufenen Zertifikat:

    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
    

    Ersetzen Sie Folgendes:

    • VERSION: Die GDC-Releaseversion. Beispiel: 1.x.y-gdch.z.
    • DIGEST_INFORMATION: die Zusammenfassungsinformationen, die Sie von Ihrem Google-Ansprechpartner erhalten haben. Die Informationen im Digest variieren je nach Release. Der 1.2.0-gdch.243-Digest unterscheidet sich beispielsweise vom 1.2.0-gdch.321-Digest. Diese Informationen werden aus Sicherheitsgründen manuell bereitgestellt.
  4. Genehmigen Sie die Änderung, wenn die ca.crt-Zertifikatsdaten mit dem heruntergeladenen Zertifikat übereinstimmen. Das Zertifikat muss wie im folgenden Beispiel aussehen:

    -----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. Prüfen Sie anhand der RootSync-Ressource, ob der Vorgang erfolgreich war. Mit einer RootSync-Ressource können alle Ressourcen im Cluster verwaltet werden, für die cluster-admin-Berechtigungen vorhanden sind. Prüfen Sie, ob die RootSync-Ressource erfolgreich gerendert wurde:

    $ kubectl --kubeconfig=$KUBECONFIG describe rootsync/root-sync -n config-management-system
    
  6. Wenn das Rendern von RootSync erfolgreich war, enthält die Ausgabe die Meldung Rendering succeeded.

  7. Wenn der Vorgang nicht erfolgreich war, liegt das Problem wahrscheinlich an einem IaC-Konfigurationsproblem. Weitere Informationen finden Sie unter Tipps zur Fehlerbehebung, um häufige IaC-Probleme zu beheben.