Os clusters do Anthos no VMware (GKE no local) usam 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 de certificação (CAs, na sigla em inglês) para cada cluster de usuário. Ele usa esses certificados de CA para emitir outros certificados de folha para componentes do sistema. O cluster de administrador gerencia a distribuição dos certificados de CA públicos e dos pares de chaves de certificados 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 serã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 CA 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
- O recurso de rotação de CA do cluster de usuário é compatível com clusters do Anthos nos clusters do VMware versão 1.8 e posteriores.
- O recurso de rotação de CA do cluster de usuário é especificamente limitado às CAs do etcd, do cluster e do proxy de referência mencionadas na visão geral. Ele não alterna sua CA org. O recurso de rotação de CA do cluster de usuário também é limitado a certificados emitidos automaticamente pelos clusters do Anthos no VMware. Ele 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 precisa reiniciar 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, espera-se que as cargas de trabalho sejam reiniciadas e reprogramadas. Também é possível esperar breves períodos de inatividade do plano de controle ao não usar uma configuração de alta disponibilidade.
- Os arquivos kubeconfig do cluster de usuário e os arquivos de configuração de autenticação para se conectar a clusters de usuário precisam ser atualizados e redistribuídos manualmente após uma rotação de CA. Isso ocorre porque uma rotação de CA necessariamente revoga a CA antiga. Portanto, essas credenciais não serão mais autenticadas.
- Depois de iniciada, não é possível pausar ou reverter uma rotação de CA.
- Uma rotação de CA pode levar um tempo considerável para ser concluída, dependendo do tamanho do cluster de usuário.
Como executar uma rotação de CA
Para iniciar uma rotação de CA e ver o status atual dela, execute os comandos gkectl abaixo.
Girar certificados de CA
Para acionar uma rotação de CA, execute o seguinte comando.
gkectl update credentials certificate-authorities rotate \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Em que:
- USER_CONFIG_FILE é o caminho para o arquivo de configuração do cluster de usuário para onde as CAs serão alternadas.
- ADMIN_KUBECONFIG_FILE é o caminho para o arquivo kubeconfig para se conectar ao cluster de administrador que gerencia o cluster de usuário.
Se a rotação de 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
Visualizar status da rotação da CA
Para visualizar o status de uma rotação de CA, execute o comando a seguir. Esse comando informa o CAVersion, um número inteiro que o sistema incrementa automaticamente para diferenciar as CAs usadas antes e depois de cada rotação de CA, um status (True ou False) que indica se a rotação de CA está concluída e
uma mensagem descrevendo qual CAVersion está em uso por cada componente do
sistema.
gkectl update credentials certificate-authorities status \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Se a rotação da CA já tiver sido concluída, você verá uma mensagem semelhante à seguinte:
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 à seguinte:
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 uma rotação de CA é concluída, é necessário fazer o download de um novo arquivo kubeconfig do cluster de usuário do cluster de administrador para substituir o kubeconfig antigo usado anteriormente na conexão com os clusters de usuário. Isso ocorre porque a rotação da CA revoga a CA antiga em que o arquivo kubeconfig antigo foi baseado. Execute o seguinte comando após a conclusão da rotação da CA para fazer o download do novo arquivo kubeconfig:
kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Se outros arquivos kubeconfig tiverem sido emitidos manualmente para outros usuários do cluster, eles também precisarão ser atualizados.
Atualizar 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:
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
o gkectl para diagnosticar 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.