Se usó la API de Cloud Translation para traducir esta página.

Rota el certificado de validación de paquetes

En esta página, se describe cómo rotar la autoridad certificadora raíz que se usa para la validación de paquetes en Google Distributed Cloud (GDC) aislado.

La validación de paquetes de GDC usa una autoridad certificadora (CA) raíz para validar los certificados de claves de lanzamiento. Por lo tanto, es fundamental rotar el certificado de la CA raíz periódicamente. Debes rotar la CA raíz si se te indica que lo hagas a través de un aviso de lanzamiento o el mensaje de advertencia que se puede mostrar cuando realices una actualización. Para obtener más información sobre el proceso de actualización, consulta Envía los artefactos al registro de contenedores.

Antes de comenzar

Para rotar el certificado de validación de paquetes, debes tener los roles de identidad y acceso necesarios:

Depurador del registro de artefactos del sistema: Tiene acceso de lectura y escritura a todos los recursos de Harbor. Pídele a tu administrador de seguridad que te otorgue el rol de clúster de depurador de Artifact Registry del sistema (sar-debugger).

Verifica si se requiere la rotación del certificado

Verifica si se requiere una rotación del certificado de validación del paquete antes de realizar la operación:

Establece la variable de entorno KUBECONFIG:
```
$ KUBECONFIG=PATH_TO_KUBECONFIG_FILE
```
Reemplaza PATH_TO_KUBECONFIG_FILE por la ruta de acceso al archivo kubeconfig que obtuviste ejecutando gdcloud auth login en el clúster de administrador raíz.

Para determinar si se requiere una actualización, compara la entidad de certificación raíz actual con la más reciente. Los datos de ConfigMap en harbor-system/package-validation-root-certs se comparan con el anclaje de confianza local:

$ 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 se debe rotar el certificado, consulta Cómo realizar la rotación y actualización de certificados.

Realiza la rotación y actualización del certificado

Usa herramientas y procesos de infraestructura como código (IaC) para rotar el objeto ConfigMap ubicado en harbor-system/package-validation-root-certs en el clúster de administrador raíz.

Crea las siguientes variables y asígnale valores:

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

Reemplaza GDC_URL por la URL de tu proyecto de GDC.

Clona el repositorio:
```
git -c http.sslVerify=false clone -b main https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac /tmp/${USERNAME}
```
Reemplaza TOKEN por tu token de acceso personal de GitLab. Para obtener más información, consulta cómo crear un token de acceso personal en https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.
Crea la carpeta de destino que contendrá los archivos de salida del proceso de rotación de certificados:
```
mkdir -p "${TARGET_FOLDER}"
```

Actualiza y reemplaza el valor 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

Verifica que la ancla de confianza se haya actualizado correctamente:

$ 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

Quita el archivo temporal que se usó para reemplazar el valor de la ancla de confianza:
```
$ rm "${TEMPLATE_FILE}" "${AWK_RULE_FILE}" "${LATEST_TRUST_ANCHOR_CA_FILE}"
```

Valida el objeto antes de confirmar el cambio:

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

Confirma el cambio:

$ 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

Crea la solicitud de combinación:

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

El resultado debe ser similar al siguiente ejemplo:

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

Una vez que se combine el cambio, deberás obtener la aprobación para la rotación del certificado de otro IO.

Obtén la aprobación para la rotación del certificado

Otro usuario de IO debe asumir el rol de aprobador y verificar este cambio. El IO que aprueba debe seguir estos pasos:

Descarga el ancla de confianza protegida de la versión de actualización objetivo en la unidad USB. Para descargar este archivo, debes tener acceso al bucket de Cloud Storage. Para obtener acceso, deriva el caso al equipo de asistencia del GDC. Para obtener más información sobre cómo descargar archivos y distribuciones de GDC, consulta Descarga archivos.
Copia la entidad de certificación raíz de la versión actualizada en el entorno aislado con la unidad USB.
Recupera el certificado y compara el certificado de la solicitud de combinación con el certificado recuperado:
```
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
```
Reemplaza lo siguiente:
- VERSION: Es la versión de la versión de GDC. Por ejemplo, 1.x.y-gdch.z
- DIGEST_INFORMATION: Es la información de resumen que recibiste de tu punto de contacto de Google. La información del resumen varía según la versión específica. Por ejemplo, el resumen 1.2.0-gdch.243 es diferente del resumen 1.2.0-gdch.321. Esta información se proporciona manualmente por motivos de seguridad.

Aprueba el cambio cuando los datos del certificado ca.crt sean los mismos que los del certificado descargado. El certificado debe verse como el siguiente ejemplo:

Para confirmar si la operación se realizó correctamente, verifica el recurso RootSync. Un recurso RootSync se puede usar para administrar cualquier recurso del clúster que tenga permisos de cluster-admin. Verifica si el recurso RootSync se renderizó correctamente:
```
$ kubectl --kubeconfig=$KUBECONFIG describe rootsync/root-sync -n config-management-system
```
Si la renderización de RootSync se realizó correctamente, el resultado incluirá el mensaje Rendering succeeded.
Si la operación no se realizó correctamente, es probable que el problema se deba a un error de configuración de IaC. Para obtener más información, consulta las sugerencias de depuración para mitigar problemas comunes de IaC.

Rota el certificado de validación de paquetes Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Antes de comenzar

Verifica si se requiere la rotación del certificado

Realiza la rotación y actualización del certificado

Obtén la aprobación para la rotación del certificado

Rota el certificado de validación de paquetes