8 commentaires
hello ! vérifie les permissions du service account k8s que vault utilise pour gcp kms. des fois après un redémarrage ou une maj de config le token du sa change ou les policies sont pas réappliquées correctement. regarde si vault a bien le droit de decrypt via kms
j'ai vérifié le service account et le rôle iam associé il a bien le kms.decrypt. je peux même faire un gcloud kms decrypt en ligne de commande depuis le pod vault avec le token du sa ça marche.
la config est la bonne j'ai rechecké le configmap et le déploiement. keyring et keyname sont corrects. pas d'écrasement apparent.
est-ce que ton vault storage backend est en bonne santé ? si le backend type consul ou etcd est corrompu ou a perdu des données suite au reboot même si kms est ok vault peut pas récupérer les clés master fragmentées pour faire l'unseal
ah ouais le backend ! on est sur consul. je vais checker les logs de consul et son état de santé. le consul server a aussi redémarré pendant la panne. ptete un souci de quorum
vous aviez raison ! un de nos trois consul servers était bloqué sur "waiting for leader". j'ai forcé son redémarrage il a rejoint le quorum et vault s'est auto-unsealed direct. merci beaucoup ! putain j'ai perdu 2h là-dessus
Laisser une réponse
Vous devez être connecté pour poster un message !
Yo la team j'ai un souci avec vault sous k8s. on a eu une coupure de courant et l'infra a redémarré. vault est censé auto-unseal avec gcp kms mais là il reste sealed. j'ai check les logs des pods vault ça dit juste "initialized but sealed". les clés kms sont toujours là je capte pas