Como alternar as autoridades de certificação do cluster de usuário

O Google Distributed Cloud usa certificados e chaves privadas para autenticar e criptografar conexões entre componentes do sistema nos clusters de usuário. O cluster de administrador cria um novo conjunto de autoridades certificadoras (CAs, na sigla em inglês) para cada cluster de usuário e usa certificados de AC 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 dos pares de chaves de certificado de folha para componentes do sistema para estabelecer a comunicação segura.

O recurso de rotação de CA 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 as CAs do sistema principal do cluster de usuário por CAs recém-geradas 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 CAs do sistema gerenciadas pelo cluster de administrador para cada cluster de usuário:

  • A CA etcd protege a comunicação do servidor da API com as réplicas do etcd e também o tráfego entre as réplicas do etcd. Essa CA é autoassinada.
  • A CA cluster protege a comunicação entre o servidor da API e todos os clientes internos da API Kubernetes (kubelets, controladores, programadores). Essa CA é autoassinada.
  • A CA do proxy frontal protege a comunicação com APIs agregadas. Essa CA é autoassinada.

Além disso, talvez você esteja usando uma AC da organização para assinar o certificado configurado pela opção authentication.sni. Essa CA 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

  • A rotação de certificados de CA é limitada às CAs do etcd, do cluster e de proxy frontal mencionadas anteriormente.

  • A rotação de certificados de CA está limitada a certificados emitidos automaticamente pelo Google Distributed Cloud. Ele não atualiza certificados emitidos manualmente por um administrador, mesmo que eles sejam assinados pelas ACs do sistema.

  • Uma rotação de AC reinicia o servidor de API, outros processos do plano de controle e cada nó no cluster várias vezes. Cada estágio de uma rotação de CA é semelhante a um upgrade de cluster. O cluster de usuário permanece operacional durante uma rotação de AC, mas as cargas de trabalho são reiniciadas e reprogramadas. Você também deverá esperar breves períodos de inatividade no plano de controle se o cluster de usuário não tiver um plano de controle de alta disponibilidade.

  • É necessário atualizar o arquivo kubeconfig do cluster de usuário e os arquivos de configuração de autenticação após uma rotação de AC. Isso ocorre 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 AC pode levar um tempo considerável para ser concluída, dependendo do tamanho do cluster de usuário.

Executar uma rotação de AC

  1. Inicie a rotação:

    gkectl update credentials certificate-authorities rotate \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Substitua:

    • USER_CLUSTER_CONFIGE: o caminho do arquivo de configuração do cluster de usuário

    • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

    Se a rotação da CA for iniciada com êxito, 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

  2. Veja o status da rotação:

    gkectl update credentials certificate-authorities status \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    O comando anterior informa 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 informa um status (True ou False) que indica se a rotação da CA foi concluída e uma mensagem que descreve qual CAVersion está em uso em cada componente do sistema.

    Se a rotação da CA já tiver sido concluída, você verá 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 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 credenciais do cluster de usuário

Após a conclusão da rotação de CA, é necessário receber um novo arquivo kubeconfig do cluster de usuário do cluster de administrador. Isso ocorre porque a rotação da AC revoga a AC em que o arquivo kubeconfig antigo foi baseado.

Receba 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

Distribua o novo arquivo kubeconfig a todos que usam um arquivo kubeconfig para interagir com o cluster.

Atualizar os 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. Siga as instruções vinculadas para atualizar e redistribuir esses arquivos após a rotação de CA:

Rotação de certificados do plano de controle

Sem rotação, as ACs do cluster de usuário e os certificados do plano de controle expiram cinco anos a partir da data de criação do cluster. Os certificados do plano de controle do cluster de usuário são alternados automaticamente em dez horas após cada upgrade de cluster de usuário, mas as CAs não são alternadas automaticamente. Isso significa que ela precisa ser realizada pelo menos uma vez a cada cinco anos, além dos upgrades regulares de versão.

Para evitar que um cluster de usuário fique indisponível, os certificados do plano de controle são alternados em dez horas após um upgrade de cluster de usuário. Quando isso acontece, uma mensagem aparece no status de rotação da AC do cluster de usuário.

Para conferir a última versão em que um cluster de usuário recebeu upgrade 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 Como diagnosticar problemas de cluster. Se você tiver problemas com a rotação de CAs, entre em contato com o Suporte do Google e forneça a saída gkectl diagnose.