Os clusters do Anthos no VMware (GKE On-Prem) usam certificados e chaves privadas para autenticar a comunicação entre os componentes do sistema do Kubernetes em um cluster de administrador. Quando você cria um cluster de administrador, novos certificados de autoridade certificadora (CA) são criados e usados para emitir outros certificados de folha para os componentes do sistema do Kubernetes.
Este guia é válido apenas para a rotação de certificados de CA do cluster de administrador. Para clusters de usuário, consulte Como rotacionar os certificados de CA do cluster de usuário.
O sistema do Kubernetes utiliza três certificados de CA em um cluster de administrador:
O certificado de CA do etcd protege a comunicação do servidor da API Kubernetes às réplicas do etcd, além da comunicação entre as réplicas do etcd. Esse certificado é autoassinado.
O certificado de CA do cluster protege a comunicação entre o servidor da API Kubernetes e todos os clientes internos da API Kubernetes, por exemplo, o kubelet, o gerenciador do controlador e o programador. Esse certificado é autoassinado.
A certificado de CA do proxy frontal protege a comunicação com APIs agregadas. Esse certificado é autoassinado.
É possível usar gkectl para acionar uma rotação de certificado. Durante uma rotação,
gkectl substitui os certificados principais da CA do sistema para o
cluster de administrador pelos certificados recém-gerados. Em seguida, ele distribui os novos
certificados de CA, certificados de folha e chaves privadas para componentes do sistema do cluster
de administrador. 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.
Sem a rotação, os certificados de AC e de plano de controle expiram cinco anos após a data de criação do cluster. Os certificados do plano de controle são alternados automaticamente durante um upgrade de cluster, mas os ACs não são alternados automaticamente. Isso significa que a rotação de um AC precisa ser realizada pelo menos uma vez a cada cinco anos, além de upgrades de versão regulares.
Limitações
Rotação de certificados de CA limitada aos certificados de etcd, de cluster e de proxy de frente mencionados anteriormente.
A rotação de certificados de CA é limitada aos certificados emitidos automaticamente pelos clusters do Anthos no VMware. A rotação não atualiza os certificados emitidos manualmente por um administrador, mesmo que esses certificados sejam assinados pelas CAs do sistema.
A rotação de certificados de CA reinicia o servidor da API Kubernetes, outros processos do plano de controle e todos os nós no cluster de administrador várias vezes. Cada estágio de uma rotação de é semelhante a um upgrade de cluster. Embora o cluster de administrador e os clusters de usuário gerenciados pelo cluster de administrador permaneçam operacionais durante uma rotação de certificado, as cargas de trabalho no cluster de administrador serão reiniciadas e reprogramadas. Espere também que haja alguns breves períodos de inatividade do plano de controle do cluster de administrador e de usuário.
Você deve atualizar o arquivo kubeconfig do cluster de administrador no meio de uma rotação de certificado e novamente após a conclusão da rotação. Isso deve ser feito porque o certificado do cluster antigo é revogado, e as credenciais no arquivo kubeconfig não funcionam mais.
Uma vez iniciada, a rotação de um certificado de CA não pode ser revertida.
Uma rotação de certificado de CA pode levar um tempo considerável para ser concluída, dependendo do tamanho do cluster.
Caso seja interrompido, o processo de rotação de certificado pode ser retomado executando novamente o mesmo comando. No entanto, é preciso garantir que haja apenas um comando de rotação sendo executado por vez.
Iniciar a rotação
Para iniciar a rotação de certificado, execute o este comando: Ele realiza a primeira metade da rotação e para em um ponto de pausa.
Inicie a rotação:
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Substitua:
ADMIN_CLUSTER_CONFIG: é o caminho do arquivo de configuração do cluster de administrador
ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador
Se o comando for interrompido, retome-o executando o mesmo comando.
Atualizar o arquivo kubeconfig
Quando o comando anterior pausar, atualize o arquivo kubeconfig do cluster de administrador. Isso coloca um novo certificado do cliente e um novo certificado de CA no arquivo kubeconfig. O antigo certificado do cliente será removido do arquivo kubeconfig e o antigo certificado de CA permanecerá no arquivo kubeconfig.
gkectl update credentials certificate-authorities update-kubeconfig \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Continuar a rotação
Execute o comando a seguir para realizar a segunda metade do procedimento. O
comando não prosseguirá até que gkectl verifique se o arquivo kubeconfig atualizado
está no diretório atual.
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--complete \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Se o comando for interrompido, retome-o executando o mesmo comando.
Quando a rotação for concluída, a versão atual da CA será informada.
Atualizar o arquivo kubeconfig novamente
Após a segunda metade da rotação, atualize o arquivo kubeconfig novamente. Isso removerá o certificado de CA antigo do arquivo kubeconfig.
gkectl update credentials certificate-authorities update-kubeconfig \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Distribuir o novo arquivo kubeconfig
Distribua o novo arquivo kubeconfig do cluster de administrador para todos os usuários do cluster.