Un backend différent avec S3

À présent nous avons gardé notre coffre en mémoire. Si notre conteneur s’arrête notre coffre est perdu. Voyons une solution plus pérenne avec un backend S3 par exemple.

L’objectif est donc que Vault aille écrire ses fichiers dans un bucket. L’utilisateur (ou système) final n’a pas besoin d’accéder à ce bucket.

Le paramétrage est très simple puisque le backend S3 est intégré de base. Paramètrons le fichier config.hcl :

backend "s3" {
  bucket = "nom"
  access_key = ""
  secret_key = ""
  region = ""
}

listener "tcp" {
 address = "0.0.0.0:8200"
 tls_disable = 1
}

Par défaut la région est us-east-1. Si votre bucket utilise cette région vous n’avez pas besoin de le préciser. Pour le reste il vous suffit de remplir les informations nécessaires.

Toutefois vous pouvez utiliser des variables d’environnements plutôt que ces valeurs, solution qui a ma préférence. Dans ce cas dans un fichier un plat, par exemple .env on peut avoir :

AWS_ACCESS_KEY_ID=
AWS_DEFAULT_REGION=
AWS_S3_BUCKET=
AWS_SECRET_ACCESS_KEY=

Il nous reste à lancer notre conteneur :

docker run --rm --name vault-server --env-file .env --cap-add IPC_LOCK -v $(pwd):/vault vault server

Vous pouvez maintenant lancer un client et l’utiliser exactement comme avant.

J’ai passé quelques temps à comprendre pourquoi j’avais systématiquement une 403 sur mon bucket quand je lançais avec le backend s3 alors qu’hors docker je n’avais pas ce souci. Il s’avère que l’heure n’était pas correcte dans mon conteneur. J’ai pu m’en rendre compte en testant avec le cli aws dans ce dernier. Si vous utilisez une VM pour lancer vos conteneurs (notamment si vous utilisez boot2docker) assurez vous que celle ci est à l’heure. Si ce n’est pas le cas vous pouvez utiliser le fichier /etc/localtime de votre hôte :

docker-machine scp /etc/localtime machine-name:/tmp/localtime
docker-machine ssh machine-name 'sudo mv /tmp/localtime /etc'

Les points de montage

Un peu plus haut je vous expliquais que nous utilisions le point de montage secret par défaut. Voyons voir ce que sont ces points de montage.

Par défaut nous avons quelques points de montage déjà disponibles :

/ # vault mounts
Path        Type       Default TTL  Max TTL  Description
cubbyhole/  cubbyhole  n/a          n/a      per-token private secret storage
secret/     generic    system       system   generic secret storage
sys/        system     n/a          n/a      system endpoints used for control, policy and debugging

À l’image d’un système de fichier les points de montage gèrent chacun les même opérations (lecture, écriture…) mais pas de la même façon. Par exemple un système de fichier peut être chiffré mais les opérations accessibles en entrée ou en sortie seront les mêmes. Pour les points de montage c’est la même chose.

Par exemple un point de montage AWS ne va pas stocker les secrets de façon brute, à l’inverse du point de montage generic. Il faut garder en tête que les backend sont cloisonnés. Un backend ne peut pas aller lire les clés d’un autre backend et c’est également vrai pour les jetons «utilisateurs».

Les points de montage peuvent donc être montés et démontés simplement :

vault mount aws
Successfully mounted 'aws' at 'aws'!