Secrets (KMS + SOPS)
Plus jamais de secret en clair, et séparation des privilèges sur les clés.
Dans le CTF, des clés AWS étaient stockées en clair dans un fichier sur S3 : quiconque lisait le bucket obtenait un accès permanent. La règle ici est simple : un secret n'existe jamais en clair, ni dans le code, ni dans un fichier, ni dans Git.
KMS, le coffre-fort à clés
AWS KMS conserve les clés de chiffrement et décide, par une politique explicite, qui a le droit de les utiliser. La clé ne sort jamais en clair. Le point clé est la séparation des privilèges :
| Identité | Droits sur la clé SOPS | Peut déchiffrer ? |
|---|---|---|
terraform-deployer (déploie) | administration (créer, supprimer) | non |
groupe-10-sops-user (applicatif) | Encrypt / Decrypt | oui, le seul |
Même si le compte de déploiement est compromis, l'attaquant n'obtient aucun secret en clair.
SOPS, le chiffrement de fichier
SOPS chiffre un fichier en s'appuyant sur la clé KMS. Seules les valeurs sensibles sont chiffrées, la structure reste lisible.
# chiffrement (seul secrets.enc.yaml part dans Git)
sops -e secrets.yaml > secrets.enc.yaml
# le fichier chiffré ressemble à :
# password: ENC[AES256_GCM,data:reW1...,iv:...,tag:...,type:str]
# host: db.internal.local # non sensible, reste lisibleLe déchiffrement (sops -d) n'est possible que pour le sops-user autorisé dans la
politique de la clé. Test réel effectué : déchiffrement refusé pour l'administrateur de la
clé, réussi pour l'identité applicative. La séparation des privilèges est donc effective.
Lien avec le CTF
La faille « clés en clair dans S3 » disparaît : le secret est chiffré, et le pouvoir de le lire est isolé sur une identité dédiée.