O Google Distributed Cloud usa certificados e chaves privadas para autenticar e encriptar ligações entre componentes do sistema em clusters de utilizadores. O cluster de administrador cria um novo conjunto de autoridades de certificação (ACs) para cada cluster de utilizador e usa certificados de AC para emitir certificados de folha adicionais para componentes do sistema. O cluster de administrador gere a distribuição dos certificados da CA pública e dos pares de chaves do certificado de folha aos componentes do sistema para estabelecer a respetiva comunicação segura.
A funcionalidade de rotação da AC do cluster de utilizadores permite-lhe acionar uma rotação dos certificados do sistema principal num cluster de utilizadores. Durante uma rotação, o cluster de administrador substitui as ACs do sistema principal do cluster de utilizador por ACs geradas recentemente e distribui os novos certificados da AC públicos e os pares de chaves de certificados de folhas aos componentes do sistema do cluster de utilizador. A rotação ocorre de forma incremental, para que os componentes do sistema possam continuar a comunicar durante a rotação. No entanto, tenha em atenção que as cargas de trabalho e os nós são reiniciados durante a rotação.
Existem três ACs do sistema geridas pelo cluster de administrador para cada cluster de utilizador:
- A AC do etcd protege a comunicação do servidor da API para as réplicas do etcd e também o tráfego entre as réplicas do etcd. Esta AC é autoassinada.
- A AC do cluster protege a comunicação entre o servidor da API e todos os clientes da API Kubernetes internos (kubelets, controladores e programadores). Esta AC é autoassinada.
- A AC do proxy frontal protege a comunicação com as APIs agregadas. Esta AC é autoassinada.
Além disso, pode estar a usar uma AC da organização para assinar o certificado configurado pela opção authentication.sni.
Esta AC e o certificado SNI são usados para disponibilizar a API Kubernetes a clientes
fora do cluster. Faz a gestão desta AC e gera manualmente o certificado SNI. Nem esta AC nem o certificado SNI são afetados pela funcionalidade de rotação da AC do cluster do utilizador.
Limitações
Tenha em atenção a seguinte limitação com os clusters avançados:
- Versão 1.31: a rotação de AC não é suportada em clusters avançados.
- Versão 1.32 e superior: a rotação da AC é suportada em clusters avançados, mas existem algumas pequenas diferenças indicadas, quando aplicável, neste documento.
A rotação de certificados da CA está limitada às CAs etcd, de cluster e front-proxy mencionadas anteriormente.
A rotação de certificados da CA está limitada a certificados emitidos automaticamente pelo Google Distributed Cloud. Não atualiza os certificados emitidos manualmente por um administrador, mesmo que esses certificados sejam assinados pelas ACs do sistema.
Uma rotação da AC reinicia o servidor da API, outros processos do plano de controlo e cada nó no cluster várias vezes. Cada fase de uma rotação de CA progride de forma semelhante a uma atualização de cluster. Embora o cluster de utilizadores permaneça operacional durante uma rotação da AC, deve esperar que as cargas de trabalho sejam reiniciadas e reagendadas. Também deve esperar breves períodos de inatividade do plano de controlo se o cluster de utilizadores não tiver um plano de controlo de alta disponibilidade.
Tem de atualizar o ficheiro kubeconfig do cluster de utilizadores e os ficheiros de configuração de autenticação após uma rotação da AC. Isto deve-se ao facto de o certificado do cluster antigo ter sido revogado e as credenciais no ficheiro kubeconfig terem deixado de funcionar.
Depois de iniciada, não é possível pausar nem reverter uma rotação de CA.
Uma rotação da AC pode demorar consideravelmente a ser concluída, consoante a dimensão do cluster de utilizadores.
Faça uma rotação da CA
Inicie a rotação:
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGSubstitua o seguinte:
USER_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de utilizadores
ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador
O comportamento do comando difere consoante o cluster avançado estar ativado:
Não ativada
Se o cluster avançado não estiver ativado no cluster, o comando é assíncrono e inicia a rotação da AC e, em seguida, termina. Não precisa de monitorizar o resultado do comando durante toda a rotação da CA. Em alternativa, pode verificar periodicamente o progresso executando o comando gkectl update credentials certificate-authorities status.
Se a rotação da AC for iniciada com êxito, é apresentada uma mensagem semelhante à seguinte:
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 já estiver em curso uma rotação de CA, é apresentada uma mensagem de erro semelhante à seguinte:
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
Para ver o estado da rotação:
gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
O comando anterior comunica 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 comunica um estado (True ou False) que indica se a rotação da AC está concluída e uma mensagem que descreve que CAVersion está atualmente a ser usado por cada componente do sistema.
Se a rotação do CA já tiver sido concluída, é apresentada 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 AC ainda estiver em curso, é apresentada 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.
Atualize as credenciais do cluster de utilizadores
Em clusters que não tenham o cluster avançado ativado, tem de obter um novo ficheiro kubeconfig do cluster de utilizadores a partir do cluster de administrador. Isto deve-se ao facto de a rotação da CA revogar a CA na qual o ficheiro kubeconfig antigo se baseava.
Obtenha um novo ficheiro kubeconfig:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Ativado
Se o cluster avançado estiver ativado, o comando gkectl update credentials
certificate-authorities rotate é síncrono. O comando produz mensagens de estado na estação de trabalho do administrador à medida que a rotação da AC progride.
Depois de a CA ser rodada com êxito, o comando é terminado e é gerado automaticamente um novo ficheiro kubeconfig. O resultado do comando fornece o nome do novo ficheiro kubeconfig e é semelhante ao seguinte:
Beginning CA rotation with generated CA ... Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has been updated.
O novo kubeconfig está localizado no mesmo diretório que o kubeconfig do cluster de administrador que especificou no comando. O nome do novo kubeconfig é USER_CLUSTER_NAME-kubeconfig.
Distribua o novo ficheiro kubeconfig
Distribua o novo ficheiro kubeconfig a todas as pessoas que usam um ficheiro kubeconfig para interagir com o cluster.
Atualize os ficheiros de configuração de autenticação
Após a conclusão da rotação da CA, os ficheiros de configuração de autenticação têm de ser atualizados e redistribuídos. Para mais informações, consulte o artigo Faça a gestão da identidade do utilizador.
Rotação de certificados do plano de controlo
Sem a rotação, as ACs do cluster de utilizadores e os certificados do plano de controlo expiram cinco anos a partir da data de criação do cluster. Os certificados do plano de controlo do cluster de utilizadores são rodados automaticamente no prazo de dez horas após cada atualização do cluster de utilizadores, mas as ACs não são rodadas automaticamente. Isto significa que tem de fazer uma rotação de CA, pelo menos, uma vez a cada cinco anos, além das atualizações de versão regulares.
Para evitar que um cluster de utilizadores fique indisponível, os certificados do plano de controlo são atualizados no prazo de dez horas após uma atualização do cluster de utilizadores. Quando isto acontece, é apresentada uma mensagem no estado de rotação da AC do cluster de utilizadores.
Para ver a última versão para a qual um cluster de utilizadores foi atualizado quando os certificados do plano de controlo foram rodados:
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
As informações aparecem no final do campo message no prazo de dez horas após uma atualização. Por exemplo:
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
Resolução de problemas de uma rotação da CA
O comando gkectl diagnose suporta a verificação do estado esperado de uma rotação de AC concluída em relação a um cluster de utilizador. Para ver instruções sobre como executar o comando
gkectl diagnose num cluster de utilizadores, consulte o artigo
Diagnosticar problemas de cluster.
Se tiver problemas com uma rotação de AC, contacte o apoio técnico da Google e
faculte o resultado do comando gkectl diagnose.