Esta página foi traduzida pela API Cloud Translation.

Rode o certificado de validação de pacotes

Esta página descreve como alternar a autoridade de certificação de raiz usada para a validação de pacotes no Google Distributed Cloud (GDC) isolado

A validação de pacotes do GDC usa uma autoridade de certificação (CA) de raiz para validar os certificados de chave de lançamento. Isto torna fundamental rodar o certificado da CA de raiz periodicamente. Tem de rodar a AC raiz se receber instruções para o fazer através de um aviso de lançamento ou da mensagem de aviso que pode ser apresentada à medida que faz uma atualização. Para mais informações sobre o processo de atualização, consulte o artigo Envie os artefactos para o registo de contentores.

Antes de começar

Para rodar o certificado de validação de pacotes, tem de ter as funções de identidade e acesso necessárias:

Depurador do Artifact Registry do sistema: tem acesso de leitura e escrita a todos os recursos do Harbor. Peça ao administrador de segurança para lhe conceder a função de cluster do depurador do Artifact Registry do sistema (sar-debugger).

Verifique se é necessária a rotação de certificados

Verifique se é necessária uma rotação do certificado de validação de pacotes antes de realizar a operação:

Defina a variável de ambiente KUBECONFIG:
```
$ KUBECONFIG=PATH_TO_KUBECONFIG_FILE
```
Substitua PATH_TO_KUBECONFIG_FILE pelo caminho para o ficheiro kubeconfig que obteve executando gdcloud auth login no cluster de administrador raiz.

Determine se é necessária uma atualização comparando a âncora de fidedignidade atual com a âncora de fidedignidade mais recente. Os dados ConfigMap em harbor-system/package-validation-root-certs são comparados com a âncora de confiança 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!

Se o certificado tiver de ser rodado, consulte o artigo Realize a rotação e a atualização do certificado.

Faça a rotação e a atualização de certificados

Use ferramentas e processos de infraestrutura como código (IaC) para rodar o objeto ConfigMap localizado em harbor-system/package-validation-root-certs no cluster de administrador raiz.

Crie e atribua valores às seguintes variáveis:

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

Substitua GDC_URL pelo URL do seu projeto do GDC.

Clone o repositório:
```
git -c http.sslVerify=false clone -b main https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac /tmp/${USERNAME}
```
Substitua TOKEN pelo seu token de acesso pessoal do GitLab. Para mais informações, veja como criar um token de acesso pessoal em https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.
Crie a pasta de destino que vai conter os ficheiros de saída do processo de rotação de certificados:
```
mkdir -p "${TARGET_FOLDER}"
```

Atualize e substitua o 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

Verifique se a âncora de confiança foi atualizada corretamente:

$ 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

Remova o ficheiro temporário que foi usado para substituir o valor da base de confiança:
```
$ rm "${TEMPLATE_FILE}" "${AWK_RULE_FILE}" "${LATEST_TRUST_ANCHOR_CA_FILE}"
```

Valide o objeto antes de confirmar a alteração:

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

Confirme a alteração:

$ 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

Crie o pedido de união:

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

O resultado tem de ser semelhante ao seguinte exemplo:

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

Assim que a alteração for unida, tem de receber aprovação para a rotação de certificados de outra IO.

Receba aprovação para a rotação de certificados

Outro utilizador da IO tem de assumir a função de aprovador e validar esta alteração. A OI de aprovação tem de seguir estes passos:

Transfira a âncora de confiança protegida da versão de atualização de destino para a unidade USB. Para transferir este ficheiro, tem de ter acesso ao contentor do Cloud Storage. Para obter acesso, encaminhe o problema para o apoio técnico do GDC. Para mais informações sobre como transferir distribuições e ficheiros do GDC, consulte o artigo Transfira ficheiros.
Copie a raiz de confiança da versão atualizada para o ambiente isolado usando a unidade USB.
Obtenha o certificado e compare-o com o certificado no pedido de união:
```
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
```
Substitua o seguinte:
- VERSION: a versão de lançamento do GDC. Por exemplo, 1.x.y-gdch.z.
- DIGEST_INFORMATION: as informações resumidas que recebeu do seu ponto de contacto da Google. As informações do resumo variam consoante o lançamento específico. Por exemplo, o resumo 1.2.0-gdch.243 é diferente do resumo 1.2.0-gdch.321. Estas informações são fornecidas manualmente por motivos de segurança.

Aprovar a alteração quando os dados do certificado ca.crt forem iguais aos do certificado transferido. O certificado tem de ser semelhante ao seguinte exemplo:

Confirme se a operação foi bem-sucedida verificando o recurso RootSync. Um recurso RootSync pode ser usado para gerir quaisquer recursos no cluster que tenham autorizações cluster-admin. Verifique se o recurso RootSync foi renderizado com êxito:
```
$ kubectl --kubeconfig=$KUBECONFIG describe rootsync/root-sync -n config-management-system
```
Se a renderização de RootSync tiver sido bem-sucedida, o resultado inclui a mensagem: Rendering succeeded.
Se a operação não tiver sido bem-sucedida, é provável que o problema se deva a um problema de configuração da IaC. Para mais informações, consulte as sugestões de depuração para mitigar problemas comuns de IaC.

Rode o certificado de validação de pacotes Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Verifique se é necessária a rotação de certificados

Faça a rotação e a atualização de certificados

Receba aprovação para a rotação de certificados

Rode o certificado de validação de pacotes