Uma conta de serviço do Kubernetes (KSA) atribui uma identidade aos processos executados em um pod.
As contas de serviço do Kubernetes são diferentes das contas de serviço do Google Cloud que os aplicativos usam para fazer chamadas autorizadas para as APIs Google Cloud.
O Google Distributed Cloud usa uma chave criptográfica privada para assinar os tokens de KSA gerados para os pods. Ele usa a chave pública correspondente para validar os tokens quando os pods enviam solicitações ao servidor da API Kubernetes. Quando um pod usa a identidade da carga de trabalho para chamar as APIs Google Cloud, o Google Cloud usa a mesma chave pública para autenticar a identidade do pod.
Durante a criação do cluster de usuário, o Google Distributed Cloud gera as chaves privadas e públicas. Também durante a criação do cluster, o Google Distributed Cloud registra o cluster em uma frota e fornece a chave pública ao Google Cloud.
Posteriormente, é possível fazer a rotação do par de chaves privadas/públicas. A rotação emite automaticamente novos tokens assinados pela nova chave privada. No final da rotação, o cluster tem uma nova chave privada, uma nova chave pública e tokens atualizados. Além disso, o Google Cloud tem a nova chave pública.
Tokens vinculados e tokens legados
Um pod pode usar um token legado ou um token vinculado para autenticação e autorização quando chama o servidor da API Kubernetes. Os tokens vinculados têm um ciclo de vida limitado e são distribuídos para os pods usando volumes projetados. Os tokens legados nunca expiram e são mantidos em secrets do Kubernetes. Recomendamos os tokens vinculados porque eles são mais seguros.
Tanto os tokens vinculados quanto os legados são atualizados durante uma rotação de chaves.
Iniciar uma rotação de chaves
Antes de iniciar uma rotação de chaves, considere estes pontos:
Durante uma rotação de chaves, não é possível iniciar outra rotação de chaves, uma autoridade de certificação ou uma atualização de cluster.
A rotação de chaves não pode ser pausada ou revertida. Todas as chaves antigas são excluídas.
A rotação de chaves exclui os nós do cluster atuais e cria novos nós.
Para iniciar uma rotação de chaves:
gkectl update credentials ksa-signing-key rotate \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONIFG \
[--skip-prompt]
Substitua:
USER_CLUSTER_CONFIG: é o caminho do arquivo de configuração do cluster de usuário
ADMIN_KUBECONFIG_FILE: o caminho do arquivo kubeconfig do cluster de administrador
Inclua --skip-prompt se não quiser ser solicitado.
Ver o status da rotação de chaves
Para ver o status de uma rotação de chaves, faça o seguinte:
gkectl update credentials ksa-signing-key status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONIFG
Se a rotação de chaves já tiver sido concluída, você verá uma mensagem como esta:
State of KSASigningKeyRotation with KSASigningKeyVersion 2 is -
status: True,
reason: KSASigningKeyRotationCompleted,
message:{"tokenVersion":2,"privateKeyVersion":2,"publicKeyVersions":[2]}
Se a rotação de chaves da assinatura de KSA ainda estiver em andamento, você verá uma mensagem semelhante a esta:
State of KSASigningKeyRotation with KSASigningKeyVersion 2 is -
status: False,
reason: KSASigningKeyRotationProcessedReason,
message:{"tokenVersion":2,"privateKeyVersion":2,"publicKeyVersions":[1,2]}