3. Gestion des secrets dans une architecture “tradi”
● Les devs/admins configurent les applications avec les secrets
● Ou pire ils sont dans le repo de code :-)
● Où sont ils stockés ?
○ dans ma tête
○ fichier local non commité
○ code / repo
○ keepass + dropbox
○ lastpass / 1password
● Que ce passe t’il quand ?
○ un secret est compromis
○ un employé quitte la société
○ la politique de sécurité prévoit de changer tous les mot de passe tous les 2 mois ?
6. Vault vue d’avion
● Solution permettant de gérer les secrets et de protéger les datas de manière
centralisée dans une infrastructure dynamique
○ Résilient
○ Scalable
○ Secure
● Basé sur un système d’APIs
● Supporte les plugins
10. Key Features
● Sécurité des secrets et data
● Rotation des clés
● Déverrouillage par saisies de plusieurs clés (3 par défaut)
● Support des policies
● Support des TTLs
● Secrets dynamiques
● UI (à partir de la 1.10)
11. Quelques use-cases sympas
● Stocker ses mot de passe qui sont ensuite récupérés par ansible
● Obtenir un user/pass mysql valide 1H uniquement
● Déverrouiller vault uniquement pendant les créneaux autorisés de MEP 💖💖
● Générer un jeu de clé AWS par user et app automatiquement
19. Audit Devices
● Destination (optionnelle) des informations d’audit où Vault envoie des logs
d’audit
● /! Contient des informations sensibles /!
● File
● Syslog
● Socket
20. Vault Plugins
● Supporte des plugins groupé en 3 catégories : auth, secret, database
● Écrits en Go avec un SDK
● On peut donc écrire le sien !
21. Déploiement
● Plusieurs options
○ from source
○ binaire en local
○ image docker
○ chart helm
○ k8s operator
● HA ou pas
● Choix du backend de stockage
● Choix du / des backends d’authentification
● Activation de l’audit ou pas
● Ecriture des rôles et policy
● Activation et configuration des plugins