O Google Distributed Cloud usa 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 (ACs) para cada cluster de usuário. Ele usa certificados de CA para emitir outros certificados de folha para componentes do sistema. O cluster de administrador gerencia a distribuição dos certificados de AC públicos e pares de chaves de certificados de folha para componentes do sistema para estabelecer a comunicação segura.
O recurso de rotação de AC 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 os certificados de CA do sistema principal do cluster de usuário por certificados de CA recém-gerados 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 são reiniciados durante a rotação.
Há três ACs do sistema gerenciadas pelo cluster de administrador para cada cluster de usuário:
- A AC etcd protege a comunicação do servidor de API com as réplicas do etcd e também o tráfego entre as réplicas do etcd. Essa CA é autoassinada.
- A AC do cluster protege a comunicação entre o servidor de API e todos os clientes internos da API Kubernetes (kubelets, controladores, escalonadores). Essa CA é autoassinada.
- A CA do proxy frontal protege a comunicação com APIs agregadas. Essa AC é autoassinada.
Além disso, você pode usar uma AC da organização para
assinar o certificado configurado pela opção authentication.sni.
Essa AC 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
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.
A rotação de certificados de CA é limitada às ACs de etcd, de cluster e de proxy de frente mencionadas anteriormente.
A rotação de certificados de CA é limitada aos certificados emitidos automaticamente pelo Google Distributed Cloud. Ela não atualiza os certificados emitidos manualmente por um administrador, mesmo que esses certificados sejam assinados pelas ACs do sistema.
Uma rotação de CA reinicia o servidor de API, outros processos do plano de controle e todos os nós 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, as cargas de trabalho serão reiniciadas e reprogramadas. Também é possível que haja breves períodos de inatividade do plano de controle se o cluster de usuário não tiver um plano de controle de alta disponibilidade.
Você precisa atualizar o arquivo kubeconfig do cluster de usuário e os arquivos de configuração de autenticação após uma rotação de CA. Isso deve ser feito porque o certificado do cluster antigo é revogado, e as credenciais no arquivo kubeconfig não funcionam mais.
Depois que uma rotação de CA é iniciada, ela não pode ser pausada ou revertida.
Uma rotação de CA pode levar um tempo considerável para ser concluída, dependendo do tamanho do cluster de usuário.
Realizar uma rotação de CA
Inicie a rotação:
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGSubstitua:
USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuários
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
Se o cluster avançado não estiver ativado no cluster, o comando será assíncrono e iniciará a rotação de CA e, em seguida, sairá. Não é necessário verificar a saída do comando durante toda a rotação de CA. Em vez disso, é possível verificar periodicamente o progresso executando o comando gkectl update credentials certificate-authorities status.
Se a rotação de CA for iniciada, 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
Para conferir o status da rotação:
gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
O comando anterior informa a 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 informa um status (True ou False) que indica se a rotação de CA foi concluída e uma mensagem descrevendo qual CAVersion está em uso no momento por cada componente do sistema.
Se a rotação de CA já tiver sido concluída, você verá uma mensagem como 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 de CA ainda estiver em andamento, você verá 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.
Atualizar as credenciais do cluster de usuário
Em clusters que não têm o cluster avançado ativado, é necessário receber um novo arquivo kubeconfig do cluster de usuário do cluster de administrador. Isso ocorre porque a rotação de CA revoga a CA em que o arquivo kubeconfig antigo foi baseado.
Receber um novo arquivo 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 será síncrono. A resposta ao comando gera mensagens de status para a estação de trabalho do administrador à medida que a rotação de CA avança.
Depois que a CA é rotacionada, o comando sai e um novo arquivo kubeconfig é gerado automaticamente. A resposta ao comando fornece o nome do novo arquivo kubeconfig e é semelhante a esta:
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 do kubeconfig do cluster de administrador especificado no comando. O nome do novo kubeconfig
é USER_CLUSTER_NAME-kubeconfig.
Distribuir o novo arquivo kubeconfig
Distribua o novo arquivo kubeconfig para todos que usam um arquivo kubeconfig para interagir com o cluster.
Atualizar arquivos de configuração de autenticação
Após a conclusão da rotação de CA, os arquivos de configuração de autenticação precisam ser atualizados e redistribuídos. Para mais informações, consulte Gerenciar a identidade do usuário.
Rotação de certificados do plano de controle
Sem a rotação, as ACs do cluster de usuário e os certificados do plano de controle expiram dez anos após a data de criação do cluster (para versões anteriores a 1.36.100, esses certificados expiram após cinco anos). Os certificados do plano de controle do cluster de usuário são rotacionados automaticamente em até dez horas após cada upgrade do cluster de usuário, mas as ACs não são rotacionadas automaticamente. Isso significa que a rotação de uma AC precisa ser realizada pelo menos uma vez a cada dez anos (cinco anos para versões anteriores a 1.36.100), além de upgrades de versão regulares.
Para evitar que um cluster de usuário fique indisponível, os certificados do plano de controle são rotacionados em até dez horas após um upgrade do cluster de usuário. Quando isso acontece, uma mensagem aparece no status de rotação de CA do cluster de usuário.
Para ver a última versão em que foi feito upgrade de um cluster de usuário quando os certificados do plano de controle foram rotacionados:
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
As informações aparecem no final do campo message em até dez horas após um upgrade. Exemplo:
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
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
gkectl diagnose em um cluster de usuário, consulte
Diagnosticar problemas do cluster.
Se você tiver problemas com uma rotação de CA, entre em contato com o suporte do Google e forneça a saída gkectl diagnose.