HashiCorp Vault : le cookbook

Si vous découvrez Vault, HashiCorp nous fournit une superbe documentation. En témoigne la prolifique section Learn du site, tenue à jour au fil des versions : https://learn.hashicorp.com/vault/. Je vous invite à vous y plonger sans retenue !

Je vous propose ici des ressources complémentaires et des zooms sur des éléments de la doc qui devraient vous être utiles dans votre aventure avec Vault, notamment sur le chemin de la production.

Comment choisir le bon backend de stockage ?

Rien de plus simple, reportez-vous à cet arbre de décision.

Veuillez noter qu’il n’est pas encore question de l’intégration du stockage à Vault annoncé avec la version v1.2.0 : ce n’est pas encore supporté par HashiCorp et l’architecture de référence reste donc celle basée sur Consul. Les choses devraient changer courant 2020, et ce sera l’occasion de faire un nouvel article à ce sujet.

Authentification des applications clientes

Deux patterns d'intégration sont présentés par Hashicorp dans le chapitre “Secure Introduction of Vault Clients” et ils couvrent tous les cas d’usage que j’ai pu rencontrer jusqu’ici. Ils offrent une résolution efficace au problème de la distribution du secret initial, permettant d’authentifier l’application cliente auprès de Vault.

Les voici résumés rapidement :

1. Platform integration. Le principe est d’utiliser la plateforme d’exécution pour fournir l’identité de la VM, du conteneur, de la fonction serverless, etc.

• Par exemple sur AWS, un appel à http://169.254.169.254/latest/dynamic/instance-identity/document depuis une VM EC2 permet d’obtenir son identité signée, et Vault peut la vérifier auprès de l’API AWS pour authentifier la VM appelante.
• Un autre exemple cette fois dans le contexte K8s : l’utilisation d’un token JWT associé à un Service Account afin d’authentifier un Workload auprès de Vault.

1. Trusted Orchestrator. Si la plateforme d’exécution ne s’intègre pas à Vault, la solution suivante consiste à faire confiance à une entité tierce : l’orchestrateur (Nomad, K8s) ou l’outil d’IaC (Puppet, Ansible, Terraform …). Le principe ici est que cette entité tierce va générer un authentifiant auprès de Vault (token, AppRole etc.), et l’injecter dans le workload qu’il instancie (VM, Conteneur etc.).

En complément de ces deux patterns, l’utilisation de Vault Agent permet de réduire l’adhérence de l’application à Vault en lui évitant de faire elle-même les différents appels au service. Vault Agent est un daemon qui s’exécute en tâche de fond. Il récupère et rafraîchit les secrets nécessaires à l’application et les lui dépose sur le système de fichier.

Il existe plusieurs alternatives à Vault Agent, dont :

• Daytona, développé par Cruise Automation et disponible sur GitHub. Il ne fonctionne que dans le pattern Platform integration et plus spécifiquement dans les contextes AWS, GCP et K8s. Très léger, il peut être utilisé comme initContainer, mais se limite à certains types de secrets.
• Vault Control Tool, développé par Hootsuite.

De mon point de vue, l’implémentation actuelle de Vault Agent est supérieure à celles de Daytona et Vault Control Tool (plus complète, mieux documentée, mieux sécurisée). Ceci dit, vu la jeunesse de Daytona et de Vault Control Tool, on peut s’attendre à ce qu’ils s’améliorent rapidement et évoluent en répondant à des cas d’usage complémentaires.

L’intégration à Kubernetes

Long story short : Vault s’intègre très bien à Kubernetes. Et étant donné la popularité actuelle de K8s, la documentation et les articles ne manquent pas sur le sujet ! J’ai sélectionné ici une paire de liens vers des outils à priori moins connus mais qui pourraient vous être bien utiles.

Le premier concerne le tout récent chart Helm fourni et maintenu par HashiCorp, qui vous permet donc de déployer Vault dans K8s aux petits oignons.

Le second lien vous emmène sur le repo de Bank Vaults, un projet de Banzai Cloud qui nous met à disposition sa boîte à outils pour Vault. Elle est composée d’un set d’outils qu’ils utilisent en interne et le projet est activement maintenu. Concrètement, ce set contient un opérateur K8s pour Vault, un binaire pour injecter des secrets de Vault dans l’ENV d’un conteneur, un wrapper du CLI Vault pour faciliter les opérations, un unsealer de Vault etc. L’ensemble est très complet et couvre une variété d’usages tous complémentaires.

La doc étant peu lisible, la meilleure source d’info que j’ai trouvé jusqu’ici sont les articles publiés sur le blog de Banzai Cloud. Je n'ai pas encore testé Bank Vaults et n’ai donc pas d’avis à vous partager dans l'immédiat. Je vous en reparlerai dès que c’est le cas !

Production Hardening

HashiCorp nous donne une liste de recommandations à appliquer pour sécuriser au mieux nos instances Vault en production. C’est un doc bien connu mais je trouve important de le garder en tête. Et je vous encourage bien évidemment à appliquer toutes les recommandations données, puisqu’elles répondent parfaitement aux modèles de sécurité et de menace élaborés par HashiCorp pour Vault.

Autre documentation utile et à laquelle on pense généralement moins souvent : celle de Consul. Elle présente le modèle de sécurité utilisé par la solution et les recommandations associées. Bien évident, ça ne concerne que les déploiements de Vault qui s'appuient sur Consul.

Monitoring & Telemetry

Hashicorp nous a fourni à tous un guide complet du monitoring pour Vault et pour son backend Consul. Ce guide a été réalisé pour Telegraf + InfluxDB + Grafana, mais il vous sera utile avec n’importe quelle autre solution de monitoring. En effet, chacune des métriques y est définie de manière intelligible, avec la signification de ses valeurs, son impact sur le comportement du système ainsi que les seuils d’alerte associés.

Un petit exemple :

Audit

L’activation de l’audit log dans Vault est indispensable d’un point de vue de la sécurité et de la gestion des incidents associée. Trois options sont disponibles pour l’écriture des logs d’audit : fichier local, socket Unix ou Syslog (local uniquement).

Mes recommandations :

• Activez l’audit pendant la phase d’initialisation de l’instance. Une bonne pratique de sécurité veut que les logs d'audit soient actifs avant toute autre opération. De plus, cette opération nécessite l'utilisation d'un token root généré à l'initialisation et que vous aurez à révoquer ensuite.
• Si vous utilisez l’option syslog, sachez qu’elle ne permet que d’envoyer à un agent local à la machine. C’est un parti pris d’implémentation de la part d’HashiCorp. De plus, Syslog est au départ un protocole basé sur UDP. Syslog over TCP n’est arrivé qu’avec la RFC 6587 en 2012. Autant dire que l’option est indisponible ou inactive sur beaucoup de serveurs. Vérifiez donc bien que vos audit logs sont envoyés sur un Syslog en TCP. En effet, UDP ne vous garantit pas le transport des paquets, et la taille des messages d’audit de Vault dépasse facilement la taille maximum d’un paquet UDP.
• Configurez au moins deux audit devices, dont au moins un de type file. Vault arrête de servir les requêtes s’il ne peut pas écrire son audit log. Activer syslog et file, par exemple, permet donc de palier à un système de fichier plein ou à un service Syslog indisponible. Et donc si vous choisissez d’activer deux audit devices de type file, faites-les pointer sur deux filesystems distincts !
• Enfin, n'utilisez socket que si vous n’avez pas d'autre option. Il permet au choix de déverser les logs dans un socket de type TCP, UDP ou UNIX. Ceci dit, la documentation précise que l’implémentation actuelle permet la perte de message (dans un cas précis et identifié, mais tout de même).

Mises à jour et known issues

La procédure de mise à jour est assez simple (merci Golang) : il suffit de faire un backup des données, puis remplacer le binaire Vault et de redémarrer le service. L’opération reste similaire en HA, avec une attention à porter en plus sur l’ordonnancement des opérations.

Mais pour bien faire, scrutez attentivement les changements apportés par la nouvelle version de Vault. HashiCorp publie un guide de mise à jour pour chaque version, et vous y trouverez des notes sur les changements de comportement de Vault, ainsi qu’une liste des problèmes connus avec cette nouvelle version.

À titre d’exemple pour la version 1.2.0 :

• un avertissement vous indique de ne pas faire la mise à jour si vous utilisez les AppRole et d’attendre un fix en 1.2.1
• des changements de comportement divers concernant les caractères acceptés dans les path des API, le retrait d’un paramètre déprécié dans les AppRole, ou encore la gestion des CN dans les groupes LDAP.

Autant dire que dès que Vault est intégré à plusieurs autres systèmes, vous aurez probablement des actions à intégrer dans votre procédure de mise jour pour traiter les impacts sur les systèmes tiers.

Administration et contrôle d’accès

Ne partez pas d’une feuille blanche pour définir les règles de contrôle d’accès aux APIs de Vault ! Hashicorp fournit dans son guide “Adopting Hashicorp Vault” un prototype de configuration basique et efficient à partir duquel itérer.

Quatre rôles y sont définis :

• Consumers, individus ou équipes qui vont créer et consommer des secrets. Potentiellement cantonnés à un namespace (version entreprise).
• Operators, administrateurs de l’instance potentiellement scopés sur un namespace aussi, et pouvant gérer les consumers, les secret engines, les policies et les moyens d’authentification.
• Key Officers, super admins avec des fonctions limitées à la rotation des clés à la définition des politiques d’audit.
• Auditers, officiers de sécurité ayant un droit d’accès aux logs d’audit de l’instance.

À l’exception des Consumers, ces rôles sont nécessaires à la bonne administration d’une instance Vault de production. Le document les décrit précisément et en donne la version déjà écrite en HCL. Exemple pour les Auditers :

Reste ensuite à faire correspondre ces rôles à des profils de votre organisation. Si ce niveau de granularité n’est pas suffisant, Vault permet d’ajouter  dans sa version enterprise des control groups. L’idée est de créer une forme de workflow d’approbation sur certaines tâches. Je vous renvoie encore une fois à la doc pour les détails d’implémentation.

Les token helpers

L’idée est de compléter le CLI Vault pour la gestion des tokens d’accès à l’API. Dans le fonctionnement par défaut, Vault va stocker le token obtenu après authentification dans le fichier ~/.vault-token. Ce fonctionnement est rapidement limité lorsque l’on travaille sur plusieurs environnements. Deux exemples de token helpers qui pourront vous servir :

• Celui fourni dans la doc Vault : un script Ruby permettant de stocker les tokens toujours dans le fichier ~/.vault-token mais en les associant à la variable $VAULT_ADDR.
• Celui créé par Joe Miller et disponible sur GitHub : en plus de mapper les tokens sur $VAULT_ADDR, il les stocke dans les porte-clés de votre OS (Windows WinCred, macOS Keychain, Linux DBus Secret Service etc.). Un must have !

Utilisez Terraform pour créer vos ressources dans Vault

Le Vault Provider de Terraform est le meilleur moyen - à ma connaissance - de gérer les ressources Vault et de les déployer dans vos différents environnements jusqu’à la production. Cela vous permet de créer et de versionner vos configs Vault dans un repo Git et de bénéficier de la bonne intégration des deux outils.

Script de mapping entre policies et authN methods

L’équipe de Green Reed Technology nous fournit gracieusement un petit script permettant d’obtenir plus d’informations opérationnelles sur nos instances Vault.

En substance, ce script récupère par API les méthodes d’authentification actives (de type userpass et AppRole seulement pour l’instant) et renvoie un JSON avec la liste des policies associées à chaque utilisateur / application. Je trouve ces informations très utiles pour auditer dans le temps les permissions données aux utilisateurs et aux applications. Quelques explications dans ce post.

Renouvellement des certificats issus d’une PKI Vault

Le projet vaultbot s’est inspiré du fonctionnement de certbot (LetsEncrypt). Programmé pour s’exécuter régulièrement, il va mettre à disposition un certificat et le renouveler dans le temps. Là encore, un outil bien pratique pour ne pas avoir à intégrer une application directement à Vault et qui vient en complément des envconsul et consul-template.

That’s all folks !

Voici pour mon petit tour des outils et recommandations pour votre aventure avec Vault. Comme vous pouvez le voir, l’écosystème est déjà riche pour un produit qui n’est arrivé à maturité qu’en décembre 2018 (date de la release v1.0), et cela devrait encore croître dans les mois à venir. Un repo GitHub à mettre dans vos favoris est d’ailleurs awesome-vault-tools.

Si besoin d’accompagnement et de conseil pour votre projet Vault, venez nous en parler !