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

O GKE no VMware 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 (CAs, na sigla em inglês) para cada cluster de usuário e usa certificados de CA 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 certificados de folha para componentes do sistema para estabelecer uma 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, talvez você esteja usando uma CA org 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

A rotação de certificados de CA é limitada às CAs etcd, de cluster e de proxy frontal mencionadas anteriormente.
A rotação de certificados de CA é limitada aos certificados emitidos automaticamente pelo GKE no VMware. Ele não atualiza certificados emitidos manualmente por um administrador, mesmo que esses certificados sejam assinados pelas CAs do sistema.
Uma rotação de AC 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, as cargas de trabalho serão reiniciadas e reprogramadas. Se o cluster de usuário não tiver um plano de controle de alta disponibilidade, aguarde breves períodos de inatividade do plano de controle.
É necessário 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 de cluster antigo é revogado e as credenciais no arquivo kubeconfig não funcionam mais.
Depois que uma rotação de CA é iniciada, não é possível pausá-la ou revertê-la.
Uma rotação de CA pode levar um tempo considerável para ser concluída, dependendo do tamanho do cluster de usuário.

Executar uma rotação de CA

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ário.
ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

Se a rotação da CA for iniciada com êxito, 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 CA já 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

Veja 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 ACs 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 está completa, e uma mensagem descrevendo qual CAVersion está sendo usada por cada componente do sistema.

Se a rotação da CA 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 CA 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 as credenciais do cluster de usuário

Após a conclusão da rotação da CA, você precisa receber um novo arquivo kubeconfig do cluster de usuário do cluster de administrador. Isso ocorre porque a rotação da CA revoga a CA em que o arquivo kubeconfig antigo foi baseado.

Receba 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 arquivo kubeconfig para interagir com o cluster.

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

Após a conclusão da rotação da CA, os arquivos de configuração de autenticação precisam ser atualizados e redistribuídos. Siga as instruções vinculadas para atualizar e redistribuir esses arquivos após a rotação de CA:

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 por cinco anos a partir da data de criação do cluster. Os certificados de plano de controle do cluster de usuário são rotacionados automaticamente em até dez horas após cada upgrade do cluster de usuário, mas as CAs não são alternadas automaticamente. Isso significa que uma rotação de CA precisa ser realizada pelo menos uma vez a cada cinco anos, além dos upgrades regulares de versão.

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

Para conferir a última versão em que um cluster de usuário recebeu upgrade para o momento em que 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 são exibidas no final do campo message em até dez horas após o 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 forneça a saída gkectl diagnose.