8 commentaires
le kms cloud c'est le mieux clair. si tu peux pas pour x raison regarde Sealed Secrets de bitnami ça chiffre tes secrets dans git et un contrôleur les déchiffre au déploiement dans le cluster. c'est mieux que rien pour le secret init même si ça reste dans k8s après.
attention avec Sealed Secrets le secret est déchiffré dans le cluster. n'importe qui avec les bonnes perms k8s peut le lire. pour l'init tu peux aussi utiliser un operator type HashiCorp Vault Operator qui gère l'init et l'unseal sans exposer ce token direct.
ok je vois le kms cloud c'est notre voie privilégiée mais on est en multi-cloud on a pas un kms unique partout. sealed secrets c'est un ptete un fallback. mais l'operator vault ça m'intéresse. il fait comment il génère le token et le gère hors de notre vue ?
l'operator gère le cycle de vie complet de vault y compris l'init et le unseal. il peut générer un token root temporaire pour setup le k8s auth method et d'autres config initiales puis le révoquer. l'idée c'est que tu n'as jamais à manipuler ce token directement.
check aussi le projet bank-vaults c'est une collection d'outils et operators autour de vault pour k8s. ils ont des solutions pour l'auto-unseal et la gestion des tokens init.
ok génial bank-vaults et l'operator c'est la piste à creuser. on va regarder ça pour l'init token et l'auto-unseal via kms dans un premier temps. thx pour les tips la team !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut la tech team j'ai un souci avec Vault sur k8s. on utilise l'auto-unseal via le k8s auth method mais au déploiement initial faut un token root pour init et pour setup l'auto-unseal. ce token il est super sensible et on sait pas trop comment le gérer de façon sécure sans le mettre en clair ou presque. des idées pour pas qu'il traîne ?