O Google Distributed Cloud usa 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 após um período desde a data de criação do cluster.
O período de expiração depende do tipo de cluster e da versão de criação:
- Clusters avançados:
- Validade de 10 anos
- Clusters não avançados:
- Criados antes da versão 1.5: validade de 10 anos
- Criados entre as versões 1.5 e 1.16: validade de cinco anos
- Criado após a versão 1.16: expiração em 30 anos
Os certificados do plano de controle são alternados automaticamente durante um upgrade de cluster, mas as CAs não são alternadas automaticamente. Isso significa que uma rotação de AC precisa ser realizada antes da data de validade da AC, além de upgrades de versão regulares.
Limitações
Observe a seguinte limitação com clusters avançados:
- Versão 1.31: a rotação de CA não é compatível com clusters avançados.
- Versão 1.32 e mais recentes: a rotação de CA é compatível com clusters avançados, mas há algumas pequenas diferenças observadas quando aplicável neste documento.
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 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.
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 seguinte comando:
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
O comportamento do comando varia dependendo se o cluster avançado está ativado:
Não ativado
O comando gkectl update credentials certificate-authorities rotate inicia e executa a primeira metade da rotação. O comando é pausado para que você execute o próximo comando e atualize o arquivo kubeconfig.
Atualizar o arquivo kubeconfig
Quando o comando gkectl update credentials certificate-authorities rotate
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 certificado do cliente antigo é removido do arquivo kubeconfig, e o certificado de CA antigo permanece 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 prossegue 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
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
Ativado
Se o cluster avançado estiver ativado, o comando gkectl update credentials
certificate-authorities rotate será síncrono. O comando gera
mensagens de status para a estação de trabalho do administrador à medida que a rotação da CA avança.
Depois que a CA é rotacionada com êxito, o comando é encerrado e um novo arquivo kubeconfig é gerado automaticamente. O arquivo kubeconfig especificado no comando é substituído por um novo. A resposta ao comando é semelhante a esta:
Beginning CA rotation with generated CA ... Successfully rotated CA for admin cluster. The kubeconfig file "/home/ubuntu/kubeconfig" has been updated. Done rotating certificate-authorities
Distribuir o novo arquivo kubeconfig
Distribua o novo arquivo kubeconfig do cluster de administrador para todos os usuários do cluster.