vault unseal auto en prod trop risqué ?

hello. le but de l'unseal manuel c'est de séparer les duties. celui qui gère l'infra et celui qui accède aux secrets. si tu automatises t'as un seul point de compromission. awskms c'est ok si ton rôle iam qui fait le unseal est ultra restreint et only for that. mais c'est un choix.

totalement d'acc avec user2. l'idéal c'est le transit seal avec hsm mais c'est cher. sinon faut blinder la politique IAM et s'assurer que le rôle ou la key KMS est pas accessible depuis les machines qui gèrent ton code app. une bonne rotation des clés KMS aussi.

on pensait à un rôle IAM avec une politique super fine genre

kms:Decrypt

ça semble une bonne approche. mais il faut aussi penser aux logs d'accès à la clé KMS. cloudtrail doit être configuré pour auditer toutes les requêtes. et des alertes si la clé est utilisée en dehors des scenarii prévus.

si tu es vraiment parano tu peux combiner. auto-unseal avec une clé kms mais avec un seuil de sharding élevé pour les clés de la KMS. genre tu as 5 opérateurs qui possèdent une part de la clé KMS et il en faut 3 pour reconstituer. ça rajoute une couche de sécu au unseal.

ouais ça c'est pour l'init des clés root au début. mais pour le unseal auto c'est une seule clé kms qui fait tout. l'important c'est que cette clé soit super bien isolée. pas de

kms:GenerateDataKey

d'acc. donc le risque est gérable avec une config IAM béton et un bon monitoring. mais il faut accepter qu'en cas de compromission de l'instance vault elle-même, l'attaquant pourrait unseal automatiquement. c'est ça le tradeoff.

exactement. c'est toujours un tradeoff entre sécu et op. mais le fait d'utiliser un service externe comme kms aide à réduire le périmètre de la "confiance". ta clé de chiffrement principale de vault ne touche jamais le disque. elle est fournie par kms à la volée. c'est déjà un gros plus.

ok on va partir là-dessus alors. avec un audit très strict sur le rôle et la clé kms. thx pour les retours les gars c'est plus clair.