Dans cette suite de 3 articles, je vous présente Vault d’Hashicorp afin de vous donner une vision sur les possibilités qu’offre cet outil pour vos différents projets. La phase d’installation est volontairement omise (le lien vers l’installation de Vault : ici). Cette suite d’article s'appuie sur mon expérience liée à l'utilisation de Vault dans le SI d’Ippon Technologies pour la gestion des secrets dans Ansible et Puppet.

Ce deuxième article rentre plus dans les détails sur les différents modules de Vault avec un exemple d’utilisation de Vault avec le module SSH.

Les Modules

Vault est composé de modules. Ces modules permettent de gérer des types de secrets (SSH, PKI, Clé/valeur), des types de stockage (Filesytem, Consul), des systèmes d’identification tiers (LDAP, Kubernetes) et des journaux (syslog, file). Ils peuvent être classés en 4 familles :

• Gestion des secrets
• Stockage
• Gestion de l'authentification au serveur Vault
• Audit

La gestion des secrets

Concernant la gestion des secrets, Vault propose une quinzaine de modules. Chaque module gère un type de secret. Par exemple, nous avons le module KV pour les clés/valeurs, ou encore le module AWS pour les access key d’IAM (service de gestion d’identité d’AWS). Voici un screenshot des modules disponibles via l’interface WEB.

A chaque module activé correspond une branche sur l’arbre des données de Vault. Le nom de la branche est choisi par l’utilisateur et plusieurs branches peuvent utiliser le même moteur de secret comme montré dans la copie d’écran suivante :

Selon les modules utilisés, les secrets peuvent être associés à un Time to live (TTL). Ce TTL correspond à une durée de vie du secret. A l’expiration de ce compteur, Vault peut être amené à exécuter des actions selon le type du secret. Par exemple, avec le module MySQL, Vault génère des comptes d’accès aux bases de données et les supprime à la fin de leur TTL.

Chaque branche agit comme un chroot etpeut être composée de section, de sous-section au nombre souhaité. Voici pour le chemin kv/client2 :

Cette notion de branche est importante dans la gestion des accès de Vault. Les autorisations d’accès pointent vers une branche ou un élément d’une branche. Dans l’exemple suivant seul le secret “client2/ansible” est concerné.

# pour le moteur KV v2
path "kv/data/client2/ansible {  # ’data’ est spécificité de la version 2 du moteur KV
capabilities = ["create"]
}

# en v1
path "secret/client2/ansible" {
capabilities = ["create"]
}

L’exemple suivant impacte toute une branche.

path "kv/data/client2/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}

#On peut ensuite interdire l’accès d’un secret particulier
path "kv/data/client2/ansible" {
capabilities = ["deny"]
}

#Ou encore
path "kv/data/+/puppet" {
capabilities = ["deny"]
}

# Note sur l’exemple:
# Le caractère ‘*’ ne correspond pas un à une regular expression. Il est supporté uniquement en dernier caractère d’un chemin
# Le caractère ‘+’ correspond à un “n’importe quel caractère”

Les autorisations sont définies dans des policies. En l’absence d’autorisation, c’est le droit DENIED qui est appliqué. Au niveau des règles de sécurité, on peut interdire, autoriser ou rendre obligatoire des paramètres sur les commandes de Vault, exemple :

# Ici on autorise la création de secret dans secret/test avec comme paramètre ‘data’ uniquement. Ce paramètre ne peut contenir que les valeurs ‘ippon’ ou ‘autres’
# Attention ici j’utilise le moteur kv v1, à la date de mes tests allowed_parameters et required_parameters ne fonctionnent pas avec le moteur kv V2 
# Issue: https://github.com/hashicorp/vault/issues/4368

path "secret/test" {
	capabilities = ["create"]
	allowed_parameters = {
		"data" = ["ippon", "autres"]
	}
}

# La commande suivante est autorisée
vault kv put secret/test data="ippon" 

# Mais pas les commandes suivantes
vault kv put secret/test data="un test"                          => permission denied
vault kv put secret/test data="ippon" autre_val=”test”  => permission denied

Les chemins des policies correspondent aux chemins utilisés par les appels API. Celles-ci acceptent des variables prédéfinies dans leurs paths. Pour plus de détails, je vous renvoie vers la documentation officielle sur les policies (ici).

Un autre point sur les policies. Celles-ci ne concernent pas uniquement les accès des secrets. Elles peuvent être appliquées aussi sur des commandes de Vault.

# Ici on autorise la commande list sur les méthodes d’identification
path "sys/auth" {
	capabilities = [ "read" ]
}

[root@vault ~]# vault auth list
Path     	Type    	Accessor              	Description
----     	----    	--------              	-----------
ansible/ 	approle 	auth_approle_324f53ab 	n/a
approle/ 	approle 	auth_approle_6654519d 	n/a
token/   	token   	            auth_token_0df76f2f   	token based credentials
userpass/	userpass	auth_userpass_406b4ac6	n/a

#Ici on autorise la création et la gestion des tokens
path "auth/token/*" {
	capabilities = [ "create", "read", "update", "delete", "list", "sudo" ]
}

Stockage

Vault propose un peu moins de 20 supports de stockage concernant les données. Il existe par exemple des modules de stockage pour S3, etcd et DynamoDB. Quel que soit le module utilisé, les données de Vault sont systématiquement stockées chiffrées.

Tous les modules de stockage proposés ne sont pas supportés directement par Hashicorp. Hashicorp supporte uniquement les modules consul, filsesystem, in-memory (non recommandé pour la production). De plus, la haute disponibilité n’est pas supportée par tous les modules de stockage.

Le choix dépend principalement de votre usage et de vos objectifs. Personnellement, je ne peux que vous conseiller d’utiliser les modules directement supportés par Hashicorp.

Audit

Vault journalise tous les appels de son API vers un fichier, syslog ou une socket selon le ou les modules d’audit activés. Au moins un module d’audit doit être activé et fonctionnel. Sans cela, Vault bloque l'exécution des commandes et se met en défaut.

Gestion de l'authentification au serveur Vault

Pour accéder au serveur Vault, on peut utiliser différentes méthodes d’authentification : elles peuvent être internes (user/password, Token) ou externes (LDAP, Radius, Kubernetes).

Voici une capture d’écran des différentes méthodes d'authentification possibles :

La documentation officielle propose plusieurs cas d’utilisation :

• AppRole (module à destination des applications et des workflows automatiques)
• AWS

Coté organisation, Vault associe différents types de méthodes d’identification (aliases) dans un objet appelé entity. Cet objet est lié à un utilisateur et peut être associé à un ou plusieurs groups. Le schéma suivant illustre cette organisation. Pour un exemple sur l’utilisation des groupes et des entity (lien vers la documentation).

Exemple d’utilisation: Module SSH

Sur le module SSH, Vault propose deux types d’identifications :

• OTP (one time password) : les identifiants ne sont valables qu’une seule fois. Vault est capable de journaliser leurs utilisations.
• Certificats SSH : Vault fonctionne en tant que CA. Chaque serveur SSH utilise la clef publique de Vault pour valider localement les certificats clients lors des tentatives de connexions SSH.

La suite de ce chapitre concerne uniquement l’identification sur les certificats SSH.

Du côté utilisateur, celui-ci doit appeler Vault afin de générer un certificat SSH. Cet appel se fait via des rôles. Les rôles permettent de forcer ou interdire des options SSH comme l’IP source, les users autorisés, le domaine DNS accessible. Ils permettent aussi de définir la durée de vie des certificats SSH clients.

Exemple d’options possibles pour les rôles :

Voici le processus pour la connexion d’un utilisateur en ligne de commande (l’équivalent existe sur l’interface web) :

• Ici l’utilisateur génère un certificat SSH

vault write -field=signed_key ssh/sign/role public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pub

• Connexion au serveur avec le certificat de l’utilisateur et celui donné par Vault

ssh -i signed-cert.pub -i ~/.ssh/id_rsa username@10.0.23.5

Note: l’argument -i signed-cert.pub peut être paramétré au niveau du fichier ssh_config

Le moteur SSH de Vault propose aussi la génération de certificat SSH à destination des hosts.

Un mot pour la fin

Le dernier article de cette suite vous proposera trois exemples d’utilisation (PKI, base de données et AWS) de Vault. La notion de secret as a service et le fonctionnement des Tokens seront abordés.