Una cuenta de servicio de Kubernetes (KSA) proporciona una identidad para los procesos que se ejecutan en un pod.
Las cuentas de servicio de Kubernetes son diferentes de las cuentas de servicio de Google Cloud que usan las aplicaciones para realizar llamadas autorizadas a las API de Google Cloud.
GKE on VMware usa una clave criptográfica privada para firmar los tokens de KSA que emite a los Pods. Usa la clave pública correspondiente para validar los tokens cuando los Pods envían solicitudes al servidor de la API de Kubernetes. Cuando un Pod usa Workload Identity para llamar a las API de Google Cloud, Google Cloud usa la misma clave pública a fin de autenticar la identidad del Pod.
Durante la creación del clúster de usuario, GKE on VMware genera las claves privadas y públicas. Además, durante la creación del clúster, GKE on VMware lo registra en una flota y proporciona la clave pública a Google Cloud.
Puedes rotar el par de claves pública/privada más adelante. La rotación emite de forma automática tokens nuevos firmados por la clave privada nueva. Al final de la rotación, el clúster tiene una clave privada nueva, una clave pública nueva y tokens actualizados. Además, Google Cloud tiene la nueva clave pública.
Tokens vinculados y tokens heredados
Un pod puede usar un token heredado o un token vinculado para la autenticación y autorización cuando llama al servidor de la API de Kubernetes. Los tokens vinculados tienen una vida útil limitada y se distribuyen a los Pods mediante volúmenes proyectados. Los tokens heredados nunca vencen y se almacenan en secretos de Kubernetes. Recomendamos los tokens vinculados porque son más seguros.
Los tokens vinculados y heredados se actualizan durante una rotación de claves.
Inicia una rotación de claves
Antes de comenzar una rotación de claves, ten en cuenta los siguientes puntos:
Durante una rotación de claves, no puedes iniciar otra rotación de claves, rotación de la autoridad certificadora ni actualización del clúster.
La rotación de claves no se puede pausar ni revertir. Se borrarán todas las claves anteriores.
Una rotación de claves borra los nodos del clúster existentes y crea nodos nuevos.
Para iniciar una rotación de claves, haz lo siguiente:
gkectl update credentials ksa-signing-key rotate \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONIFG \
[--skip-prompt]
Reemplaza lo siguiente:
USER_CLUSTER_CONFIG: La ruta de acceso del archivo de configuración del clúster de usuario
ADMIN_KUBECONFIG_FILE: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
Incluye --skip-prompt si no quieres que se te solicite.
Visualiza el estado de una rotación de claves
Para ver el estado de una rotación de claves, haz lo siguiente:
gkectl update credentials ksa-signing-key status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONIFG
Si ya se completó la rotación de claves, verás un mensaje similar al siguiente:
State of KSASigningKeyRotation with KSASigningKeyVersion 2 is -
status: True,
reason: KSASigningKeyRotationCompleted,
message:{"tokenVersion":2,"privateKeyVersion":2,"publicKeyVersions":[2]}
Si la rotación de la clave de firma de KSA aún está en curso, verás un mensaje similar a este:
State of KSASigningKeyRotation with KSASigningKeyVersion 2 is -
status: False,
reason: KSASigningKeyRotationProcessedReason,
message:{"tokenVersion":2,"privateKeyVersion":2,"publicKeyVersions":[1,2]}