Mots de passe, certificats, clés d’API… comment gérer ces informations sensibles et leur cycle de vie ? Si vous stockez vos mots de passe dans Gitlab par exemple, ce n’est peut-être pas une bonne pratique de sécurité, et cet article est pour vous. Nous vous proposons de découvrir le fonctionnement de Hashicorp Vault, solution de Secret as a Service, que nous avons couplée à Consul pour fournir un outil de gestion des secrets dans un pipeline CI/CD.

Article réalisé en collaboration avec Adrien Nouvel

Vault ou le Secret as a Service

Vault est l’équivalent d’un coffre-fort qui permet de stocker des secrets comme des mots de passe, des certificats, des clés SSH, sous forme de clé-valeur. L’avantage de Vault est qu’il est modulaire, qu’il peut être couplé à des bases de données ou d’autres services, et que la centralisation des informations sensibles dans Vault évite de stocker les mots de passe dans l’application. D’autres outils sur le marché permettent de stocker des mots de passe, mais aucun n’offre cette facilité d’intégration avec des services tiers (secret engines). On peut parler de Secret as a Service.

Comment fonctionne Vault ?

Prenons l’exemple d’un utilisateur se connectant à une base de données: Vault génère un mot de passe à la volée, et à chaque nouvelle connexion un mot de passe temporaire est généré. Vault étant connecté à la base de données, il peut générer à la demande des accès utilisateurs avec des droits spécifiques. Quand les opérations sont terminées, Vault procède alors à la révocation de cet accès. La flexibilité de Vault offre beaucoup d’applications en termes de sécurité. Par exemple, si on considère que une ou plusieurs applications ont été corrompues, Vault peut refuser l’accès à ces applications.

Retour d’expérience sur Vault

Dans le cadre d’un projet client, Vault a été choisi pour décorréler la gestion des secrets des applications elles-mêmes. La sécurité des applications est en effet déportée au niveau de Vault, de façon à ce qu’elle puisse être gérée par des Ops. Chaque nouvelle application déployée est connectée à Vault, et ne dispose d’aucun accès aux mots de passe et certificats qui sont gérés par Vault.

Vault, Consul et les produits Hashicorp (dont nous sommes partenaires) sont développés dans l’optique de faire des systèmes distribués sur le modèle cloud; dans le cas du déploiement on premise, cela pose certaines contraintes supplémentaires du fait que certains services ne sont pas dans le Cloud. Dans le contexte de ce projet, le système d’authentification pour l’administration du Vault était on premise et n’autorisait qu’un nombre limité de machines. Or dans le modèle cloud, on a besoin d’une plage d’adresses plus large que ce que la sécurité autorise. Pour répondre à cette contrainte, nous avons développé un socle commun permettant à l’infrastructure on premise de s’adapter aux systèmes distribués. Par ailleurs, Vault devant à terme être utilisé par de nombreuses applications, la contrainte de sécurité est très forte et demande de nombreuses validations.

Si Vault peut être utilisé seul, il est complètement intégré dans la chaîne des outils Hashicorp, et il est beaucoup plus efficace utilisé en combinaison. Par exemple utilise Consul en tant que backend de stockage de Vault, et on déploie le tout avec Terraform. Les produits Hashicorp sont interdépendants, mais cette interdépendance fonctionne bien, et les outils sont conçus pour créer une chaîne, même s’ils peuvent être utilisés indépendamment. Consul étant très complémentaire de Vault, c’est le sujet que nous allons traiter maintenant.

Plus de détails sur le sujet dans l’article « How Vault Encrypts Application Data« 

Consul

Consul, système distribué développé par Hashicorp, est un système de stockage clé valeur, comme une base de données. L’avantage de Consul est qu’il est distribué, et donc plusieurs instances se partagent le volume de données. En cas de perte d’un noeud, il en reste toujours d’autres et le service reste accessible. Dans le contexte du projet cité plus haut, Consul a été utilisé comme outil de stockage des informations Vault. Quand un utilisateur fait une demande à un service Vault, Vault prend la requête, et va chercher les mots de passe dans un cluster Consul. Lors de la création d’un nouveau secret, les informations sont chiffrées par Vault et stockées dans Consul ; Vault ne contient aucune donnée.

Consul est également utilisé comme Service discovery. Grâce à un système d’agents, Consul peut découvrir les instances sur un réseau. Tous les agents communiquent avec le serveur, et on interroge l’agent Consul pour identifier les noeuds. Ce service de DNS est dynamique : les instances s’enregistrent lors du lancement, et le serveur Consul vérifie régulièrement l’état des noeuds pour identifier les instances éteintes.

Consul, de la sandbox à la production

Il y a encore quelques mois, nous n’avions jamais travaillé sur Consul et Vault. Pour commencer, la documentation Hashicorp est un bon point de départ. Elle est fournie, on y trouve des exemples de déploiements existants, et il est aussi possible de s’inspirer des modules développés par la communauté.

Ensuite, nous avons commencé à expérimenter sur un environnement de sandbox. Par exemple, nous voulions un cluster de cinq noeuds, nous avons lancé cinq instances, sur lesquelles nous avons installé Consul pour voir comment cela fonctionnait. Nous avons travaillé de façon itérative, en essayant tout d’abord de faire communiquer 5 noeuds consul, puis puis d’ajouter les features une par une, en automatisant avec Terraform et Packer.

On commence par une image système basique, elle est déployée avec Terraform, puis on met à jour l’image avec une nouvelle fonctionnalité, etc. Ensuite, on passe au déploiement sur un environnement non production, avant de passer au cluster complet sur l’environnement de production. Aujourd’hui encore, nous travaillons de cette façon : pour ajouter une fonctionnalité, nous passons par la sandbox, puis on passe en recette et en production quand la fonctionnalité est validée.

Vers une gestion des secrets intégrée dans la chaîne CI/CD

Dans le cadre de ce projet client, nous travaillons actuellement à la mise en place d’une chaîne de déploiement des services sur AWS. Notre objectif est de rationnaliser et standardiser ce process, pour qu’il permette de mettre à jour les images de façon automatique, et simple. Pour mieux gérer le cycle de vie des services à déployer sur AWS, l’idée est de créer un template utilisable par les équipes et de capitaliser sur l’expertise et les bonnes pratiques. A terme, nous voulons fournir un ensemble d’outils pour le déploiement de services, permettant de gérer facilement le multi-compte et les environnements multiples sur AWS avec Terraform . Le build, le déploiement et les mises à jour seront effectués avec le minimum d’outils possibles : Packer, Terraform, Ansible, Git.

Plus de détails sur ce projet dans le talk « A way to share secrets in your pipeline » lors des Hashidays le 26 Juin 2018