Hashicorp a annoncé en Juin dernier le lancement de sa plateforme Hashicorp Cloud Platform. Ces derniers jours, ils ont annoncé que Vault serait disponible sur cette plateforme.

Encore en bêta, il manque de nombreuses fonctionnalités d'automatisation pour approcher d’une solution viable en production : impossible de piloter les snapshots par API, d’accéder aux logs sans passer par l’interface, pas encore de réplication...

Mais les principes de base sont là et sont très facilement accessibles ! C’est donc, à date, une très bonne idée pour se familiariser à Vault, qui pourrait à l’avenir, devenir une très bonne alternative à la version non-managée.

Si nous avons déjà parlé plusieurs fois de Vault sur ce blog, nous pouvons rappeler rapidement les quelques principales fonctionnalités clefs de ce produit :

• Coffre-fort centralisé de votre infrastructure : Vault se veut le référentiel unique de vos secrets. De fait, c’est également vers lui que se tourneront les applications, pour aller récupérer les différents secrets dont elles auront besoin.
• Accès aux secrets restreints : l’accès aux secrets se fait via l’identification et des “policies” finement paramétrables. Il est par ailleurs possible de brancher Vault à pléthore de fournisseurs d’identités (parmi les plus connus : LDAP, JWT/OIDC, Github, Azure, AWS, ...) afin de s’en servir comme fédérateur.
• Secrets dynamiques : il est possible de configurer Vault pour créer des secrets “à la volée”, pouvant avoir une durée de vie potentiellement très courte (par exemple, un accès à certaines tables de votre base de donnée pour un script batch qui n’est censé durer que quelques minutes, utiliser Vault comme PKI…)
• API-first : tout est bien évidemment pilotable par API et tous ses appels sont enregistrés dans des logs et donc auditables.
• Sécurisé : cela va sans dire, mais Vault se veut sécurisé. Les données et les communications sont chiffrées par défaut et surtout, Vault facilite l’utilisation de patterns qui sans lui seraient complexes à implémenter, voire mal implémentés.

HCP: someone else’s computer?

HCP (pour Hashicorp Cloud Plateform) est le système proposé par Hashicorp pour déployer leurs produits de manière managée. Aujourd’hui, Vault est le second produit à y être disponible, après Consul (ou le troisième, si l’on considère Terraform Cloud comme faisant réellement partie de HCP).

Se connecter à HCP est très simple et peut se faire via votre compte (et organisation) Github.

Comme on peut le voir dans cette vidéo, les services disponibles via HCP reposent sur le principe du HVN (Hashicorp Virtual Network). Le HVN est un réseau virtuel déployé sur un fournisseur de cloud et dans une région donnée. Il sera ensuite appairé (peered) à votre propre réseau sur votre fournisseur cloud. Grâce à cela, nous pourrons communiquer avec notre cluster Vault (ou Consul) sans passer par Internet, en restant sur notre réseau privé !

Pour le moment, seul AWS est disponible et sur un nombre de régions restreint (seulement sur us-west-2 pour Vault par exemple). Une autre limitation observée lors de notre test semble être de ne pouvoir instancier qu’un seul HVN par compte. On peut néanmoins aisément imaginer, dans le futur, la réplication de nos clusters Vault se faire entre plusieurs régions, entre plusieurs clouds providers.

Déployé et Opéré par Hashicorp

C’est la version Enterprise qui est déployée, en haute disponibilité (de type “standby”). Via le portail, il est aujourd’hui possible de :

• Générer un nouveau token d’administration qui vous permettra de faire l’intégralité des opérations sur votre cluster. Il sera valable 6h.
• Faire des Snapshots manuels (et restaurer un snapshot antérieur)
• Accéder à un rapide aperçu de la santé du cluster (très succinct)
• Possibilité de Seal / Unseal (opération qui s’est par ailleurs soldée par une erreur 500 lorsque nous avons voulu le faire via API)
• Accéder aux Audit logs : attention toutefois, on n’accède uniquement à la dernière heure ! et via l’interface (“au clic”).

Bref, vous l’aurez compris : le strict minimum est aujourd’hui disponible. Il s’agit bel et bien d’une bêta, avec laquelle il est néanmoins possible de jouer, mais absolument pas “prod ready”.

C’est gratuit ?

Oui ! Lors de nos tests, nous n’avons pas pu observer le coût d’une telle solution. Effectivement, si nous disposons à notre inscription sur le HCP d’un crédit de 20$, l’utilisation de ressources Vault en bêta n’est pas facturée (“Vault beta resources will not utilize your credits.”).

Je veux tester !

Les étapes pour commencer sont très simples et il est possible d’activer le fait de pouvoir joindre votre cluster via une IP publique. Bien évidemment, nous ne pouvons suffisamment insister sur le fait de ne pas faire cela autrement qu’en phase exploratoire.

Dans notre cas, cela a pris ~9 minutes avant que notre cluster soit fonctionnel.

Ensuite, il faudra bien évidemment se référer à la documentation.

Commençons par exporter l’adresse de notre cluster Vault (en partant du principe que vous avez le binaire Vault installé bien sûr.

$ export VAULT_ADDR=https://vault-cluster.vault.abcd.aws.hashicorp.cloud:8200

Puis utilisons la commande de login pour vérifier que cela est possible. Pour cela, nous devons au préalable générer un token sur l’interface de Vault HCP.

$ vault login Token (will be hidden): Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key                  Value ---                  ----- token                s.XXXXXXXXXXXX token_accessor       mxXurOuD56U9zv1eie0OiXko.Es2Xq token_duration       5h59m26s token_renewable      false token_policies       ["default" "hcp-root"] identity_policies    [] policies             ["default" "hcp-root"]

Nous pouvons voir ici que les policies associées sont : celle par default (“default”) et une policy que nous ne connaissons pas. Avant d’aller regarder ce qui se cache derrière celle-ci, regardons le statut du cluster

$ vault status Key                                    Value ---                                    ----- Recovery Seal Type                     shamir Initialized                            true Sealed                                 false Total Recovery Shares                  1 Threshold                              1 Version                                1.6.0+ent Cluster Name                           vault-cluster-e3393a92 Cluster ID                             ca1502b2-609e-59d4-86e1-5af77b5024e0 HA Enabled                             true HA Cluster                             https://1.2.3.4:8201 HA Mode                                standby Active Node Address                    https://node-1-0.vault-cluster.private.vault.abcd.aws.hashicorp.cloud:8202 Performance Standby Node               true Performance Standby Last Remote WAL    275 Raft Committed Index                   2480 Raft Applied Index                     2480

Cela nous permet de voir que le cluster est effectivement en mode “High Availability”.

Regardons donc notre fameuse policy “hcp-root“.

Comme nous sommes dans un environnement namespaced, il est nécessaire de nous placer dans le bon namespace pour lire notre policy.

$ export VAULT_NAMESPACE=admin $ vault policy list default hcp-root $ vault policy read hcp-root path "*" { capabilities = ["sudo","read","create","update","delete","list"] }

Si vous êtes familiers avec la mécanique interne de Vault (que l’on peut résumer comme suit : “un token porte des policies qui s’appliquent sur des paths de secrets”), vous comprendrez que notre la policy hcp-root nous permet de tout faire. Même les capacités “sudo”.

La liste des chemins nécessitant les capacités sudo peut se trouver ici : Policies - root-protected API endpoints. Je peux vérifier cela grâce à la commande suivante, me permettant de vérifier mes droits sur le endpoint permettant de “seal” le coffre-fort (le “fermer” en cas d’attaque détectée) :

$ vault token capabilities s.xxxxx sys/seal create, delete, list, read, sudo, update

Pourtant, lorsque j’essaie réellement de tenter cette opération, cela se solde par un échec :

$ vault operator seal Error sealing: Error making API request. URL: PUT https://vault-cluster.vault.abcd.aws.hashicorp.cloud:8200/v1/sys/seal Code: 404. Errors: * 1 error occurred: * unsupported path

Toutes les commandes d’operator (generate-root, init, key-status...) donnent le même résultat. Ce qui n’est pas choquant dans le cadre d’une solution managée (sauf pour le seal, que l’on aimerait pouvoir piloter en dehors de l’interface web).

Côté fonctionnalités, Vault n’a pas besoin de nous convaincre : c’est une solution qui se fait rapidement son chemin dans les infrastructures. Ici, cette bêta sur HCP nous offre toutes les fonctionnalités “utilisateurs” (lire et écrire des secrets...) et “administrateurs” (provisionner un secret engine…). C’est du côté des fonctionnalités d’exploitation que nous attendons des évolutions (pilotage par API des logs, snapshots, seal…).

Nous apprécions par ailleurs particulièrement le modèle du HCN à la fois simple et élégant.

Il reste la question du prix qui sera à surveiller plus tard, pour savoir si cette solution est réellement intéressante.