Migração de CA no local

Observação: este guia descreve como migrar sua autoridade certificadora (CA, na sigla em inglês) sem migrar as cargas de trabalho para um novo plano de controle (no local) com tempo de inatividade mínimo usando uma ferramenta baseada em bash. Para migrar da CA do Istio para a CA do Mesh com uma abordagem baseada em canário que envolve tempo de inatividade mínimo ou inexistente, consulte Migração baseada em canário para a CA do Mesh.

Se sua malha tiver vários clusters com cargas de trabalho que enviam solicitações para cargas de trabalho em outro cluster, siga todas as etapas neste guia para todos os clusters.

Siga as etapas deste guia para os casos de uso a seguir:

• Migrar um plano de controle do Anthos Service Mesh v1.13 ou posterior no cluster com a CA da malha para o Certificate Authority Service.
• Migre um plano de controle gerenciado do Anthos Service Mesh em um canal de lançamento que é mapeado para a v1.13 ou posterior com a CA da malha para o Certificate Authority Service.

Limitações

As migrações e upgrades de CA no local só são compatíveis com o Anthos Service Mesh v1.13 ou mais recente. Para migrações gerenciadas do plano de controle, verifique se o canal escolhido é mapeado para a v1.13 ou posterior.

Pré-requisitos

Antes de seguir as etapas deste guia, verifique se você:

• Concedeu permissões de administrador do cluster
• Configurou gcloud

Além disso, verifique se você está usando o Anthos Service Mesh v1.13 ou posterior.

Ferramentas necessárias

Durante a migração, você executa uma ferramenta fornecida pelo Google, migrate_ca. Essa ferramenta tem as seguintes dependências:

• awk
• grep
• jq
• kubectl
• head
• sed
• tr
• yq

Antes de fazer o download da ferramenta migrate_ca, siga as etapas em Preparar-se para a migração.

Visão geral da migração

Durante o processo de migração, a autenticação e a autorização estão totalmente funcionais entre as cargas de trabalho que usam a CA anterior e as cargas de trabalho que usam a nova CA.

A ferramenta de migração migrate_ca criará um mapa de configuração do Kubernetes para rastrear o status da migração da CA por revisão/canal do Anthos Service Mesh instalado. Esse é um recurso privilegiado instalado no namespace istio-system.

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

A ferramenta de migração fará backup do mapa de configuração do Istio MeshConfig antes de alterá-lo. Além disso, ela tentará migrar a configuração da CA usando o CRD ProxyConfig sempre que possível.

Veja a seguir um resumo da migração da CA:

Observação: é preciso executar as etapas de migração em cada cluster na sua malha.

1. Preparo para a migração.

2. Inicializar a nova CA.

3. Adição de TrustedAnchors em toda a malha para todos os clusters da frota.

4. Migrar a CA.

5. Fazer uma reversão.

Preparo para a migração

1. Faça o download da ferramenta bash migrate_ca:

   curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
   

2. Torne a ferramenta executável:

   chmod +x migrate_ca
   

3. Configure o diretório de trabalho:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Observação: se você não especificar um diretório de trabalho, um diretório temporário será criado. Você precisará usá-lo como o diretório de trabalho para todas as etapas próximas.

4. Altere o diretório de trabalho para o OUTPUT_DIR especificado na etapa anterior.

   cd OUTPUT_DIR
   

5. Execute o comando a seguir para garantir que todos os pré-requisitos sejam atendidos:

   ./migrate_ca check-prerequisites
   

6. Anote a revisão (ASM_REVISION) do plano de controle associado à CA anterior que está sendo migrada. As etapas necessárias dependem do tipo de plano de controle, seja no cluster ou gerenciado.

   No cluster

   asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
    "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
   

   Grupo

   Consulte o canal já instalado.

7. Como a migração da CA no local exige que você reinicie as cargas de trabalho, verifique se o Orçamento de interrupção do pod está configurado corretamente, e todos os aplicativos com a CA que precisa ser migrada têm mais de um pod em execução.

8. Verifique se o cluster já está registrado em uma frota e se a identidade da carga de trabalho está ativada no cluster. Em seguida, anote o ID do projeto da frota como (FLEET_ID) para etapas futuras.

9. A ferramenta aceita kubeConfig e kubeContext para selecionar o cluster em que as operações são realizadas. Se esses argumentos não forem transmitidos, o contexto/configuração padrão será usado.

   • Para adicionar as credenciais de um cluster do GKE ao kubeConfig, use o seguinte comando:

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Para mudar o contexto kubectl atual ou transmitir o contexto para a ferramenta, use o seguinte comando:

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Inicializar a nova CA

1. As etapas necessárias para inicializar a nova CA dependem da nova CA para a qual você está migrando. Execute essas etapas em cada cluster de frota para onde você quer migrar a CA.

   CA da malha

   Chame o subcomando initialize da ferramenta de utilitário.

   Se você estiver especificando configurações personalizadas do Kubernetes, faça o seguinte:

    ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
   

   Se esse não for seu caso, faça o seguinte:

    ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
    ```
   

   Serviço de CA

   a. Siga as etapas necessárias para inicializar o Certificate Authority Service. Anote o CA_POOL.

   b. Chame o subcomando initialize da ferramenta de utilitário:

   Se você estiver especificando configurações personalizadas do Kubernetes, faça o seguinte:

    ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
    --fleet-id FLEET_ID --revision ASM_REVISION
   

   Se esse não for seu caso, faça o seguinte:

     ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
   

Adição de TrustedAnchors em toda a malha para todos os clusters da frota.

1. Repita as etapas abaixo para a nova CA e para a CA antiga para todos os clusters que fazem parte da frota.

2. Faça o download doTrustAnchors da CA:

   CA da malha

   ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
   

   Serviço de CA

   Armazene o certificado da CA em um arquivo:

   gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
   

3. Adição de TrustedAnchors da CA:

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. Verifique se os trustedAnchors foram recebidos por todas as cargas de trabalho na frota. No argumento de namespaces, transmita todos os namespaces em que as cargas de trabalho são implantadas:

   ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Resposta esperada:

   Check the CA cert in namespace nsa-1-24232
   a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
   

Migrar a CA

1. Migrar a configuração da CA. O comando necessário depende da nova CA para a qual você está migrando.

   CA da malha

   ./migrate_ca migrate-ca --ca mesh_ca
   

   Serviço de CA

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. Reiniciar todas as cargas de trabalho.

   Observação: esta etapa será opcional se você tiver instalado o plano de dados gerenciado. Isso ocorre porque o Google gerencia os ciclos de vida do proxy e executa automaticamente essa etapa durante um upgrade gerenciado.

   Para minimizar o risco de inatividade do tráfego TLS, esta etapa precisa afetar o menor número de cargas de trabalho primeiro. Reinicie somente as cargas de trabalho associadas à revisão do plano de controle ASM_REVISION. Por exemplo, se todas as cargas de trabalho no namespace NAMESPACE do Kubernetes estiverem associadas ao mesmo plano de controle do Anthos Service Mesh.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Verifique se as conexões mTLS funcionam entre as cargas de trabalho no namespace reiniciado e outras cargas de trabalho antes de repetir as etapas 1 e 2 para todos os namespaces e para todos os clusters que fazem parte da frota. Se novas cargas de trabalho estiverem chegando e o tráfego da malha não for interrompido, repita as etapas 1 e 2 para todos os namespaces e clusters que fazem parte da frota. Caso contrário, prossiga para a reversão da configuração mais recente da CA.

4. Verifique se a nova configuração de CA está sendo usada por todas as cargas de trabalho:

   ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Resposta esperada:

   Check the CA configuration in namespace nsb-2-76095
   b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
   

Fazer uma reversão

1. Reverta a configuração da CA e remova os trustedAnchors recém-configurados:

   ./migrate-ca rollback
   

2. Reiniciar todas as cargas de trabalho. Reinicie apenas as cargas de trabalho associadas à revisão do plano de controle ASM_REVISION. Por exemplo, se todas as cargas de trabalho no namespace NAMESPACES do Kubernetes estiverem associadas ao mesmo plano de controle do Anthos Service Mesh.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Opcional) Verifique se a configuração da CA mais antiga está sendo usada por todas as cargas de trabalho.

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. Repita as etapas 1 a 3 para todos os clusters na frota em que as cargas de trabalho usam o plano de controle ASM_REVISION.

Parabéns! Você executou uma migração da CA no local.