Esta página se ha traducido con Cloud Translation API.

Rotar el certificado de validación de paquetes

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

La validación de paquetes de GDC usa una autoridad de certificación (CA) raíz para validar los certificados de clave de lanzamiento. Por eso, es fundamental cambiar el certificado de 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 del mensaje de advertencia que puede mostrarse al realizar una actualización. Para obtener más información sobre el proceso de actualización, consulta Enviar los artefactos al registro de contenedores.

Antes de empezar

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

Depurador de System Artifact Registry: tiene acceso de lectura y escritura a todos los recursos de Harbor. Pide a tu administrador de seguridad que te conceda el rol de clúster Depurador de Artifact Registry del sistema (sar-debugger).

Verificar si es necesario rotar el certificado

Verifica que es necesario rotar el certificado de validación de un paquete antes de realizar la operación:

Define la variable de entorno KUBECONFIG:
```
$ KUBECONFIG=PATH_TO_KUBECONFIG_FILE
```
Sustituye PATH_TO_KUBECONFIG_FILE por la ruta del archivo kubeconfig que has obtenido ejecutando gdcloud auth login en el clúster de administrador raíz.

Determina si es necesario actualizar comparando la ancla de confianza actual con la más reciente. Los datos de ConfigMap en harbor-system/package-validation-root-certs se comparan con el ancla 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 el certificado debe rotarse, consulta Rotar y actualizar certificados.

Realizar la rotación y la actualización de certificados

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

Crea las siguientes variables y asígnales 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

Sustituye 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}
```
Sustituye 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 sustituye 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

Comprueba que el 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

Elimina el archivo temporal que se ha usado para sustituir el valor del 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

La salida debe tener el siguiente aspecto:

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 haya combinado el cambio, debes obtener la aprobación para la rotación del certificado de otro IO.

Obtener la aprobación para la rotación de certificados

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 de destino en la unidad USB. Para descargar este archivo, debes tener acceso al segmento de Cloud Storage. Para obtener acceso, ponte en contacto con el equipo de Asistencia de GDC. Para obtener más información sobre cómo descargar distribuciones y archivos de GDC, consulta Descargar archivos.
Copia el ancla de confianza de la versión actualizada en el entorno aislado mediante la unidad USB.
Obtén el certificado y compáralo con el certificado de la solicitud de combinación:
```
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
```
Haz los cambios siguientes:
- VERSION: la versión de lanzamiento de GDC. Por ejemplo, 1.x.y-gdch.z.
- DIGEST_INFORMATION: la información resumida que has recibido de tu contacto de Google. La información del resumen varía en función de la versión concreta. 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 tener el siguiente aspecto:

Para confirmar si la operación se ha completado correctamente, consulta el recurso RootSync. Un recurso RootSync se puede usar para gestionar cualquier recurso del clúster que tenga permisos cluster-admin. Comprueba si el recurso RootSync se ha renderizado correctamente:
```
$ kubectl --kubeconfig=$KUBECONFIG describe rootsync/root-sync -n config-management-system
```
Si la renderización de RootSync se ha completado correctamente, el resultado incluirá el mensaje Rendering succeeded.
Si la operación no se ha realizado correctamente, es probable que el problema se deba a un problema de configuración de IaC. Para obtener más información, consulta los consejos para depurar y mitigar los problemas habituales de IaC.

Rotar el certificado de validación de paquetes Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Verificar si es necesario rotar el certificado

Realizar la rotación y la actualización de certificados

Obtener la aprobación para la rotación de certificados

Rotar el certificado de validación de paquetes