Configurar o Certificate Authority Service no Cloud Service Mesh gerenciado

Neste guia, descrevemos como configurar o Certificate Authority Service no Cloud Service Mesh gerenciado. Para informações sobre o Cloud Service Mesh no cluster, consulte Instalar recursos padrão e serviço de autoridade de certificação (CA).

Observação :não é possível usar o Certificate Authority Service (CA Service) ao usar a configuração padrão da frota no GKE Enterprise e registrar clusters na frota durante a criação deles. Para usar o CA Service, recomendamos configurar o Cloud Service Mesh por cluster.

Além da autoridade de certificação do Cloud Service Mesh, é possível configurar o Cloud Service Mesh para usar o Certificate Authority Service. Este guia oferece uma oportunidade de integração com o serviço de CA, o que é recomendado para os seguintes casos de uso:

• Se você precisar de autoridades de certificação diferentes para assinar certificados de carga de trabalho em clusters diferentes.
• Se você precisar fazer backup das chaves de assinatura em um HSM gerenciado.
• sua empresa é altamente regulada e está sujeita a conformidade.
• Se você quiser encadear a CA do Cloud Service Mesh a um certificado raiz corporativo personalizado para assinar certificados de carga de trabalho.

O custo da autoridade de certificação do Cloud Service Mesh está incluído nos preços do Cloud Service Mesh. O serviço de CA não está incluído no preço base do Cloud Service Mesh e é cobrado separadamente. Além disso, o serviço de CA vem com um SLA explícito, mas a autoridade de certificação do Cloud Service Mesh não.

Configurar o serviço de CA

1. Crie o pool de CAs no nível DevOps e na mesma região que o cluster usado para evitar problemas de excesso de latência ou possíveis interrupções entre regiões. Saiba mais em Níveis otimizados para carga de trabalho.
2. Crie a CA para ter pelo menos uma autoridade certificadora ativa no pool de CAs no mesmo projeto que o cluster do GKE. Use ACs subordinadas para assinar certificados de carga de trabalho do Cloud Service Mesh. Anote o pool de CAs correspondente à CA subordinada.

3. Se ela se destinar apenas a certificados de serviço para cargas de trabalho do Cloud Service Mesh, configure a seguinte política de emissão para o pool de AC:

   policy.yaml

   baselineValues:
     keyUsage:
       baseKeyUsage:
         digitalSignature: true
         keyEncipherment: true
       extendedKeyUsage:
         serverAuth: true
         clientAuth: true
     caOptions:
       isCa: false
   identityConstraints:
     allowSubjectPassthrough: false
     allowSubjectAltNamesPassthrough: true
     celExpression:
       expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
   

   Observação: como prática recomendada para malhas de vários clusters, defina um pool de CAs subordinadas por região de cluster exclusiva. Todos os pools de CAs subordinadas precisam estar encadeados ao mesmo pool de CAs raiz.

4. Para atualizar a política de emissão do pool de CAs, use o seguinte comando:

   gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
   

   Para informações sobre como definir uma política em um pool, consulte Como usar uma política de emissão de certificado.

5. Se você estiver usando um modelo de certificado, configure-o agora. Para mais informações, siga o Guia de serviço de CA para certificados de identidade da carga de trabalho. Verifique se o modelo de certificado foi criado na mesma região do pool de CAs. Se houver várias regiões para pools de CAs, crie um modelo de certificado por região.

Papéis necessários para usar o serviço de AC

Para essa integração, todas as cargas de trabalho no Cloud Service Mesh exigem os seguintes papéis do IAM:

    WORKLOAD_IDENTITY="PROJECT_ID.svc.id.goog:/allAuthenticatedUsers/"

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project PROJECT_ID \
      --location ca_region \
      --member "group:${WORKLOAD_IDENTITY}" \
      --role "roles/privateca.workloadCertificateRequester"

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project PROJECT_ID \
      --location ca_region \
      --member "group:${WORKLOAD_IDENTITY}" \
      --role "roles/privateca.auditor"

Se estiver usando modelos de certificado:

    gcloud privateca templates add-iam-policy-binding CERT_TEMPLATE_ID \
        --member "group:${WORKLOAD_IDENTITY}" \
        --role "roles/privateca.templateUser"

Limitações

• Configure e escolha a AC antes de provisionar o plano de controle do Cloud Service Mesh. Não é possível alterar a CA.

Configurar o Cloud Service Mesh gerenciado para usar o serviço de AC

Observação :conclua todas as etapas a seguir antes de ativar o gerenciamento automático.

1. Verifique se o namespace istio-system existe ou crie-o se estiver ausente:

     kubectl create ns istio-system
   

2. Verifique se o configmap asm-options existe no namespace istio-system:

     kubectl get configmap/asm-options -n istio-system
   

3. Crie o configmap se ele não existir:

     kubectl create configmap -n istio-system asm-options
   

4. Corrija o configmap para adicionar a configuração do CAS:

     kubectl patch configmap/asm-options -n istio-system --type merge \
     -p '{"data":{"ASM_OPTS": "CA=PRIVATECA;CAAddr=projects/PROJECT_ID/locations/ca_region/caPools/CA_POOL"}}'
   

   Se um modelo de certificado for necessário, anexe o ID do modelo ao endereço do pool de AC usando : como separador:

     kubectl patch configmap/asm-options -n istio-system --type merge \
     -p '{"data":{"ASM_OPTS": "CA=PRIVATECA;CAAddr=projects/PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID"}}'
   

Depois de concluir as etapas de configuração, ative o gerenciamento automático para continuar a instalação do Cloud Service Mesh gerenciado.