Esta página foi traduzida pela API Cloud Translation.

Alternar o certificado de validação de pacote

Nesta página, descrevemos como alternar a autoridade certificadora raiz usada para validação de pacotes no Google Distributed Cloud (GDC) isolado por air-gap.

A validação de pacotes do GDC usa uma autoridade de certificação (CA) raiz para validar certificados de chave de lançamento. Por isso, é fundamental fazer a rotação periódica do certificado da CA raiz. Você precisa fazer a rotação da CA raiz se receber instruções para isso em um aviso de lançamento ou na mensagem de alerta que pode aparecer durante um upgrade. Para mais informações sobre o processo de upgrade, consulte Enviar os artefatos para o Container Registry.

Antes de começar

Para fazer a rotação do certificado de validação de pacote, você precisa ter os papéis de identidade e acesso necessários:

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

Verificar se a rotação do certificado é necessária

Verifique se é necessário fazer uma rotação de certificado de validação de pacote 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 arquivo kubeconfig que você obteve ao executar gdcloud auth login no cluster de administrador raiz.

Compare a âncora de confiança atual com a mais recente para determinar se é necessário fazer um upgrade. 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 precisar ser alternado, consulte Executar a rotação e o upgrade do certificado.

Fazer a rotação e o upgrade do certificado

Use ferramentas e processos de infraestrutura como código (IaC) para fazer a rotação do 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, consulte 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 arquivos 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 arquivo temporário usado para substituir o valor da âncora de confiança:
```
$ rm "${TEMPLATE_FILE}" "${AWK_RULE_FILE}" "${LATEST_TRUST_ANCHOR_CA_FILE}"
```

Valide o objeto antes de confirmar a mudança:

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

Faça commit da mudança:

$ 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 a solicitação de mesclagem:

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

A saída será semelhante ao exemplo a seguir:

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

Depois que a mudança for mesclada, você precisará receber a aprovação para a rotação de certificados de outro IO.

Receber aprovação para a rotação de certificado

Outro usuário do IO precisa assumir a função de aprovador e verificar essa mudança. O IO de aprovação precisa seguir estas etapas:

Faça o download da âncora de confiança protegida da versão de upgrade de destino para o drive USB. Para fazer o download desse arquivo, você precisa ter acesso ao bucket do Cloud Storage. Para ter acesso, encaminhe o caso ao suporte do GDC. Para mais informações sobre como fazer o download de distribuições e arquivos do GDC, consulte Fazer o download de arquivos.
Copie a âncora de confiança da versão atualizada para o ambiente isolado usando o pen drive.
Extraia o certificado e compare o certificado na solicitação de mesclagem com o certificado extraído:
```
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:
- VERSION: a versão do lançamento do GDC. Por exemplo, 1.x.y-gdch.z.
- DIGEST_INFORMATION: as informações de resumo que você recebeu do seu ponto de contato do Google. As informações do resumo variam de acordo com a versão específica. Por exemplo, o resumo 1.2.0-gdch.243 é diferente do resumo 1.2.0-gdch.321. Essas informações são fornecidas manualmente por motivos de segurança.

Aprove a mudança quando os dados do certificado ca.crt forem iguais aos do certificado baixado. O certificado precisa ser semelhante ao exemplo a seguir:

Confirme se a operação foi bem-sucedida verificando o recurso RootSync. Um recurso RootSync pode ser usado para gerenciar qualquer recurso no cluster que tenha permissões cluster-admin. Verifique se o recurso RootSync foi renderizado:
```
$ kubectl --kubeconfig=$KUBECONFIG describe rootsync/root-sync -n config-management-system
```
Se a renderização de RootSync for bem-sucedida, a saída vai incluir a mensagem: Rendering succeeded.
Se a operação não for bem-sucedida, o problema provavelmente é devido a uma configuração de IaC. Para mais informações, consulte Dicas de depuração para reduzir problemas comuns de IaC.

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

Antes de começar

Verificar se a rotação do certificado é necessária

Fazer a rotação e o upgrade do certificado

Receber aprovação para a rotação de certificado

Alternar o certificado de validação de pacote