Como rotacionar certificados de CA do cluster de administrador

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.