Como alternar as autoridades de certificação do cluster de usuário

O Google Distributed Cloud usa certificados e chaves privadas para autenticar e criptografar conexões entre componentes do sistema em clusters de usuários. O cluster de administrador cria um novo conjunto de autoridades certificadoras (ACs) para cada cluster de usuário e usa certificados de AC para emitir outros certificados de folha para componentes do sistema. O cluster de administrador gerencia a distribuição dos certificados de AC públicos e dos pares de chaves de certificado de folha para os componentes do sistema para estabelecer a comunicação segura.

O recurso de rotação de CA do cluster de usuário permite acionar uma rotação dos certificados do sistema principal em um cluster de usuário. Durante uma rotação, o cluster de administrador substitui as CAs do sistema principal do cluster de usuário por CAs recém-geradas e distribui os novos certificados de CA públicos e pares de chaves de certificados de folha para os componentes do sistema do cluster de usuário. A rotação acontece gradualmente para que os componentes do sistema continuem se comunicando durante a rotação. No entanto, as cargas de trabalho e os nós são reiniciados durante a rotação.

Há três CAs do sistema gerenciadas pelo cluster de administrador para cada cluster de usuário:

  • A CA etcd protege a comunicação do servidor da API com as réplicas do etcd e também o tráfego entre as réplicas do etcd. Essa CA é autoassinada.
  • A CA cluster protege a comunicação entre o servidor da API e todos os clientes internos da API Kubernetes (kubelets, controladores, programadores). Essa CA é autoassinada.
  • A CA do proxy frontal protege a comunicação com APIs agregadas. Essa CA é autoassinada.

Além disso, você pode usar uma AC da organização para assinar o certificado configurado pela opção authentication.sni. Essa CA e o certificado SNI são usados para exibir a API Kubernetes para clientes fora do cluster. Você gerencia essa CA e gera manualmente o certificado SNI. Nem essa CA nem o certificado SNI são afetados pelo recurso de rotação de CAs de cluster de usuário.

Limitações

  • Se você criou o cluster com enableAdvancedCluster definido como true (o que é necessário para configurar domínios de topologia), a rotação do certificado da AC não é compatível.

  • A rotação de certificados de CA é limitada às CAs do etcd, do cluster e do proxy frontal mencionadas anteriormente.

  • A rotação de certificados de CA é limitada aos certificados emitidos automaticamente pelo Google Distributed Cloud. A rotação não atualiza os certificados emitidos manualmente por um administrador, mesmo que esses certificados sejam assinados pelas CAs do sistema.

  • Uma rotação de CA reinicia o servidor da API, outros processos do plano de controle e cada nó no cluster várias vezes. Cada estágio de uma rotação de CA é semelhante a um upgrade de cluster. Embora o cluster de usuário permaneça operacional durante uma rotação de CA, é esperado que as cargas de trabalho sejam reinicializadas e reprogramadas. Também é possível esperar breves períodos de inatividade do plano de controle se o cluster de usuário não tiver um plano de controle de alta disponibilidade.

  • Você precisa atualizar o arquivo kubeconfig do cluster de usuário e os arquivos de configuração de autenticação após uma rotação de CA. Isso ocorre porque o certificado do cluster antigo é revogado, e as credenciais no arquivo kubeconfig não funcionam mais.

  • Depois que uma rotação de CA é iniciada, ela não pode ser pausada ou revertida.

  • Uma rotação de CA pode levar um tempo considerável para ser concluída, dependendo do tamanho do cluster de usuário.

Fazer uma rotação de CA

  1. Inicie a rotação:

    gkectl update credentials certificate-authorities rotate \
        --config USER_CLUSTER_CONFIG \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    Substitua:

    • USER_CLUSTER_CONFIGE: o caminho do arquivo de configuração do cluster de usuários

    • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

    Se a rotação de CA for iniciada, você verá uma mensagem semelhante a esta:

    successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation
    

    Se uma rotação de AC estiver em andamento, você verá uma mensagem de erro semelhante a esta:

    Exit with error:
    admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads
    
  2. Confira o status da rotação:

    gkectl update credentials certificate-authorities status \
        --config USER_CLUSTER_CONFIG \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    O comando anterior informa o CAVersion, que é um número inteiro que o sistema incrementa automaticamente para diferenciar as CAs usadas antes e depois de uma rotação. O comando também informa um status (True ou False) que indica se a rotação da CA foi concluída e uma mensagem descrevendo qual CAVersion está em uso por cada componente do sistema.

    Se a rotação da AC já tiver sido concluída, você verá uma mensagem semelhante a esta:

    State of CARotation with CAVersion 2 is -
    status: True,
    reason: CARotationCompleted,
    message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.
    

    Se a rotação da AC ainda estiver em andamento, você verá uma mensagem semelhante a esta:

    State of CARotation with CAVersion 2 is -
    status: False,
    reason: CARotationProgressed,
    message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.
    

Atualizar credenciais do cluster de usuário

Depois que a rotação da CA for concluída, você precisará receber um novo arquivo kubeconfig do cluster de usuário do cluster de administrador. Isso ocorre porque a rotação da AC revoga a AC em que o arquivo kubeconfig antigo foi baseado.

Obtenha um novo arquivo kubeconfig:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
    -n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
    | base64 --decode > USER_CLUSTER_NAME-kubeconfig

Distribua o novo arquivo kubeconfig para todos que usam um kubeconfig para interagir com o cluster.

Atualizar arquivos de configuração de autenticação

Após a conclusão da rotação da AC, os arquivos de configuração de autenticação precisam ser atualizados e redistribuídos. Para mais informações, consulte Gerenciar a identidade do usuário.

Rotação de certificados do plano de controle

Sem a rotação, as ACs do cluster de usuário e os certificados do plano de controle expiram cinco anos após a data de criação do cluster. Os certificados do plano de controle do cluster de usuário são alternados automaticamente em até 10 horas após cada upgrade do cluster de usuário, mas as ACs não são alternadas automaticamente. Isso significa que a rotação de uma AC precisa ser realizada pelo menos uma vez a cada cinco anos, além de upgrades de versão regulares.

Para evitar que um cluster de usuário fique indisponível, os certificados do plano de controle são rotacionados em até 10 horas após um upgrade do cluster de usuário. Quando isso acontece, uma mensagem aparece no status de rotação de CA do cluster de usuário.

Para conferir a última versão em que foi feito upgrade de um cluster de usuário quando os certificados do plano de controle foram alternados:

gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG

As informações aparecem no final do campo message em até 10 horas após um upgrade. Exemplo:

Last Leaf Certificates Rotation Version: 1.16.0-gke.0.

Solução de problemas de uma rotação de CA

O comando gkectl diagnose permite verificar o status esperado de uma rotação de CA concluída em um cluster de usuário. Para instruções sobre como executar gkectl diagnose em um cluster de usuário, consulte Como diagnosticar problemas de cluster. Se você tiver problemas com uma rotação de CA, entre em contato com o Suporte do Google e informe a saída gkectl diagnose.