Le compte de service Kubernetes (KSA) fournit une identité aux processus exécutés dans un pod.
Les comptes de service Kubernetes sont différents des comptes de service Google Cloud que les applications utilisent pour effectuer des appels autorisés vers les API Google Cloud.
GKE sur VMware utilise une clé cryptographique privée pour signer les jetons KSA qu'il émet aux pods. Il utilise la clé publique correspondante pour valider les jetons lorsque les pods envoient des requêtes au serveur d'API Kubernetes. Lorsqu'un pod utilise Workload Identity pour appeler les API Google Cloud, Google Cloud authentifie l'identité du pod à l'aide de la même clé publique.
Lors de la création du cluster d'utilisateur, GKE sur VMware génère les clés privées et publiques. Toujours lors de la création du cluster, GKE sur VMware enregistre le cluster dans un parc et fournit la clé publique à Google Cloud.
Vous pourrez par la suite alterner la paire de clés privée/publique. La rotation émet automatiquement de nouveaux jetons signés par la nouvelle clé privée. À la fin de la rotation, le cluster dispose d'une nouvelle clé privée, d'une nouvelle clé publique et de jetons actualisés. De plus, Google Cloud dispose de la nouvelle clé publique.
Jetons liés et anciens jetons
Lorsqu'il appelle le serveur d'API Kubernetes, un pod peut utiliser un jeton hérité ou un jeton lié pour l'authentification et l'autorisation. Les jetons liés ont une durée de vie limitée et sont distribués aux pods à l'aide de volumes projetés. Les anciens jetons n'expirent jamais et sont conservés dans des secrets Kubernetes. Nous vous recommandons d'utiliser des jetons liés, car ils sont plus sécurisés.
Les jetons liés et les anciens jetons sont actualisés lors d'une rotation des clés.
Démarrer une rotation des clés
Avant de commencer une rotation des clés, tenez compte des points suivants:
Lors d'une rotation des clés, vous ne pouvez pas lancer une autre rotation des clés, rotation de l'autorité de certification ou mise à jour du cluster.
La rotation des clés ne peut pas être suspendue ni annulée. Toutes les anciennes clés sont supprimées.
Une rotation des clés supprime les nœuds de cluster existants et en crée d'autres.
Pour démarrer une rotation des clés:
gkectl update credentials ksa-signing-key rotate \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONIFG \
[--skip-prompt]
Remplacez les éléments suivants :
USER_CLUSTER_CONFIG: chemin d'accès au fichier de configuration du cluster d'utilisateur
ADMIN_KUBECONFIG_FILE: chemin d'accès au fichier kubeconfig du cluster d'administrateur
Incluez --skip-prompt si vous ne souhaitez pas y être invité.
Afficher l'état d'une rotation des clés
Pour afficher l'état d'une rotation des clés:
gkectl update credentials ksa-signing-key status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONIFG
Si la rotation des clés est déjà terminée, un message semblable à celui-ci s'affiche:
State of KSASigningKeyRotation with KSASigningKeyVersion 2 is -
status: True,
reason: KSASigningKeyRotationCompleted,
message:{"tokenVersion":2,"privateKeyVersion":2,"publicKeyVersions":[2]}
Si la rotation des clés de signature du KSA est toujours en cours, un message semblable à celui-ci s'affiche:
State of KSASigningKeyRotation with KSASigningKeyVersion 2 is -
status: False,
reason: KSASigningKeyRotationProcessedReason,
message:{"tokenVersion":2,"privateKeyVersion":2,"publicKeyVersions":[1,2]}