Temps de lecture : 11 minutes

Développé par Hashicorp, Vault est un outil de gestion des secrets (mots de passe, certificats, clés d’API), visant à stocker les secrets de façon sécurisée. L’intérêt de l’outil est sa flexibilité pour stocker tous types de secrets de façon statique ou dynamique (secret temporaire et variable) et ce quel que soit l’environnement (AWS, Database, Certificat, …). Vault se base sur une ou plusieurs méthodes d’authentification (là aussi le système est flexible) afin de permettre aux consommateurs de secret d’interagir, mais la variété de ces méthodes d’authentification et d’environnement rend le choix difficile. Dans cet article, nous allons passer en revue l’ensemble des méthodes d’authentification de Vault (aussi appelées Auth backend), et les cas d’usage auxquels elles sont les plus adaptées.

Prérequis

Dans un premier temps, pour ceux qui n’ont jamais eu l’occasion de voir à quoi ressemble Vault, je vous invite à essayer le tutoriel interactif sur le site officiel Vault d’Hashicorp afin de vous faire une première idée, ou à lire cet article sur le sujet.

Dans un second temps, il faut savoir qu’à l’heure d’écriture de cet article, Vault est en version 0.10.4 et que le produit n’est pas encore complet. Certaines méthodes d’authentification peuvent changer ou disparaître.

Enfin, l’ensemble des méthodes d’authentifications ainsi que les informations relatives à la configuration ou utilisation peuvent se trouver sur le site officiel de Vault.

Les méthodes d’authentification

Parmis les 13 méthodes d’authentification, nous allons voir le contexte d’utilisation et les réponses apporté aux problématiques par ces méthodes.

Voici une liste des méthodes ainsi que les liens relatifs à la documentation:

• AppRole
• AWS
• Azure
• Google Cloud
• JWT/OIDC
• Kubernetes
• GitHub
• LDAP
• Okta
• RADIUS
• TLS Certificates
• Tokens
• Username & Password

Chaque méthode d’authentification permet d’associer une ou des ACL Policies, qui sont des droits (capabilities) d’actions sur le Vault: la lecture, la création, la mise à jour, le listing et enfin la suppression.

De plus, il est possible d’activer plusieurs méthodes d’authentification différentes (AWS, Azure, Google Cloud, etc.) mais aussi du même type (ex: LDAP pour l’annuaire A et un deuxième LDAP pour l’annuaire B).

La subtilité du choix réside donc dans l’utilisation équilibrée de plusieurs méthodes, chacune adaptée à un contexte précise. Il faut donc dans un premier temps séparer les consommateurs physiques et les applications.

Nous avons donc 3 types de méthodes orientées :

• Token (spécial)
• Humaine
• Applicative

Token

Méthode d’authentification de Vault qui est au coeur du système et implémentée par défaut. Toutes les autres méthodes d’authentification se basent sur celle-ci: elle retournent toutes un token après authentification.

Cette méthode ne sert pas d’authentification d’identité (contrairement aux autres) mais permet d’authentifier les droits associés au token avec le Vault.

Cas d’usage

Le cas d’usage le plus fréquent, en dehors du fait que les autres méthodes d’authentification se basent sur celle-cii, est de générer des tokens enfants ou à durée limitée.

Exemple: Un opérateur de Vault souhaite exécuter une pipeline afin d’effectuer du CI/CD sur Vault. Celui-ci va donc générer un token enfant à durée limitée, le temps de l’exécution du pipeline.

A retenir

• Dans un contexte d’authentification, cette méthode n’apporte aucune authentification d’identité et ne doit être utilisée en aucun cas par un utilisateur physique ou un service.
• Dans un contexte de développement et de test de la solution Vault, c’est la méthode d’authentification la plus simple et rapide à utiliser.
• Enfin, l’usage direct de cette méthode peut être envisageable pour un cas comme cité plus haut où l’authentification d’identité a été effectuée en amont par une autre méthode d’authentification.

Méthode orientée humaine

Username & Password

La méthode Userpass ou encore appellé “Username & Password” est une méthode d’authentification locale à Vault pour les utilisateurs physiques. L’utilisateur ainsi que le mot de passe sont à définir via l’API que Vault fournit.

Cas d’usage

Comme toute méthode d’authentification locale avec username et mot de passe, celle-ci est utile dans un environnement de test et découverte du Vault. La configuration et l’usage est simple et rapide. Cette méthode est destinée aux utilisateurs physiques.

A savoir qu’il est possible de restreindre l’authentification Userpass par un range CIDR (paramètre: bound_cidrs) autrement dit, de faire un filtrage IP.

A retenir

• Dans le contexte d’une grande entreprise, il est impensable de gérer chaque utilisateur (création, modification de mot de passe, suppression) avec cette méthode. Il faudra donc s’orienter sur des méthodes comme LDAP ou RADIUS;
• Pour les entreprises les plus petites n’ayant aucun système d’annuaire et ayant un nombre d’utilisateurs limité de 2 à 3, il est envisageable d’utiliser cette méthode de façon temporaire avec filtrage IP.
• Enfin, il est possible pour une application d’utiliser cette méthode mais uniquement en dernier recours si aucune autre méthode n’est envisageable. Il faudra, dans un premier temps, s’orienter vers des méthodes comme Approle, TLS certificates, etc…

Github

Utile pour toute organisation utilisant Github. Cette méthode permet d’utiliser l’authentification github avec un personal access token.

Cas d’usage

Idéal dans le cas où une entreprise utilise Github. La méthode permet au sein d’une organisation Github de mettre en relation une ou plusieurs teams d’organisation Github avec des ACL policies Vault. Ce qui inclut donc les utilisateurs comme les développeurs.

A retenir

• Vault ne supporte pas le workflow OAuth pour la génération de GitHub tokens. Il est donc fortement déconseillé d’utiliser cette méthode d’authentification en tant qu’application.
• Une dépendance forte à Github. Tous les utilisateurs de Vault ne sont pas forcément sur Github, il faut donc coupler cette méthode avec une autre.

LDAP

La méthode LDAP permet, comme son nom l’indique, d’utiliser les annuaires se basant sur le protocole LDAP. Cette méthode d’authentification permet d’identifier soit un utilisateur soit un groupe LDAP.

Cas d’usage

Cette méthode évite la duplication de configuration username/password dans plusieurs endroits ainsi que sa gestion. Elle est idéale pour les utilisateurs physiques mais peu adaptée pour les comptes de services. Sa configuration nécessite une connaissance de l’annuaire LDAP mais une fois configurée, la méthode est adaptée pour un environnement de production.

A retenir

• Idéale pour les utilisateurs physiques dans une entreprise de grande taille puisqu’elle permet une authentification par groupe ou utilisateur.
• Dans un contexte applicatif/serveur avec des comptes de services, cette méthode peut être envisagée. Cependant, elle n’apporte pas un niveau suffisant d’authentification d’identité comme pourraient le faire d’autres méthodes (ex: Le filtrage IP manquant).
• La configuration nécessite une connaissance de l’annuaire LDAP.

RADIUS

Dans la même logique que la méthode LDAP, elle permet d’utiliser le protocole RADIUS.

Cas d’usage

Même logique que l’authentification LDAP.

A retenir

• Contrairement au LDAP, nous n’avons aucune notion de groupe. Il faudra donc ajouter manuellement chaque utilisateur RADIUS dans la configuration du Vault. Ce qui n’est pas envisageable pour un annuaire de grande entreprise.
• Dans certains cas où un niveau d’authentification forte est demandé, le RADIUS peut répondre à cette problématique. L’astuce est donc d’activer et configurer RADIUS pour les administrateurs Vault et le LDAP pour les utilisateurs consommant les services de Vault.

Méthode orientée applicative

Approle

Selon moi Approle est la méthode d’authentification applicative la plus universelle et la plus simple d’utilisation dans un workflow automatisé.

D’une part, cette méthode fait abstraction de l’environnement où l’application se situe (cloud, on-premises, container, etc).

D’autre part, si la méthode est bien implémentée, elle permet à l’application d’être seule à récupérer son token Vault lors de son déploiement. En d’autres termes, la méthode permet une isolation totale à l’application sur la lecture de ses secrets (même les développeurs ne peuvent lire le secret).

Cet méthode se base sur deux informations afin d’authentifier l’application: Le role ID et le secret ID.

Usage

(source: https://www.vaultproject.io/guides/identity/authentication.html)

Comme le montre le schéma ci-dessus, nous avons 3 acteurs: l’administrateur Vault, une trusted entity et l’application.

L’objectif pour ces 3 acteurs est :

• Administrateur Vault: Créer le AppRole auth backend et récupérer le role ID de l’application.
• La trusted entity: Récupérer le secret ID.
• L’application: Récupérer les deux informations auprès des autres acteurs et s’authentifier avec.

Ici, seule l’application est apte à obtenir son Vault token et à lire ses secrets contrairement aux administrateurs et à la trusted entity.

Enfin, l’objectif est de limiter la durée de vie du secret ID. En d’autres termes, la durée du secret ID doit être égale au temps de déploiement de l’application afin qu’elle récupère un token Vault (ex: 10 minutes).

Il est bon de savoir qu’avec cette méthode, il est possible de :

• Limiter le login avec role ID et secret ID avec un range CIDR
• Limiter l’utilisation du token Vault avec un range CIDR

A retenir

• Il faut avoir un workflow automatisé avec une trusted entity pour que la génération du Vault token ne soit pas fastidieuse pour l’administrateur Vault ou encore éviter qu’elle ne soit corrompue.
• Toutes les applications ne se configurent pas avec un outil de management de configuration ou via un orchestrateur. Il n’est donc pas impossible que dans certains cas l’administrateur doit se charger de la génération du role ID et du secret ID, ce qui impose une charge opérationnelle supplémentaire comme le démontre le schéma ci-dessous:

(source: https://www.vaultproject.io/guides/identity/authentication.html)

TLS Certificates

La méthode TLS Certificates est tout aussi universelle et simple d’utilisation si on met de côté la gestion et le cycle de vie des certificats.

La configuration de Vault doit se faire en amont en y plaçant un certificat de confiance (la clé publique) afin que le client puisse s’authentifier. Cette méthode fonctionne donc aussi avec les certificats auto-signés.

Cas d’usage

Certaines applications comme les sites web possèdent leurs propres certificats. Il est donc naturel d’intégrer cette méthode avec les applications ayant déjà ce système de certificat.

Côté client Vault, celui-ci devra fournir : le certificat CA (de préférence), son certificat et sa clé.

A retenir

• Pour les applications n’ayant pas de certificat ou ne prenant pas en compte la gestion des certificats, il est préférable de passer par la méthode Approle.
• Pour les applications déployées dans un système automatisé prenant en compte la génération du certificat, cette méthode est idéale car elle s’intègre parfaitement au workflow. Il faudra donc incorporer le certificat applicatif à la configuration de la méthode dans le workflow.
• Pour les applications déployées dans un système où la gestion et/ou la génération du certificat n’est pas automatisée, celle-ci donnera une surcharge de travail à l’administrateur Vault afin de configurer la méthode d’authentification.

AWS/Azure/Google Cloud

Ici, j’ai regroupé les trois méthodes AWS, Azure et Google Cloud dans une seule section car elles ciblent toutes le cloud public et le procédé reste le même. De plus, pour faire au plus simple, je me baserai sur AWS mais comme dit précédemment, le procédé reste le même.

Nous avons deux types de workflow: EC2 et IAM. Dans les deux cas, Vault aura besoin de privilèges sur AWS (se référer: https://www.vaultproject.io/docs/auth/aws.html#recommended-vault-iam-policy).

Concernant la partie EC2, Vault se basera sur la signature (le PKCS7) de l’instance EC2 afin de vérifier l’identité de celle-ci et de certaines informations propres à l’instance (région, VPC ID, etc). Vault devra donc avoir les accès pour lire les metadata des instances EC2.

Ci dessous un schema illustrant le workflow:

(source: https://www.vaultproject.io/docs/auth/aws.html#ec2-auth-method)

Les informations sur lesquelles Vault peut se baser afin d’authentifier une instance EC2 sont: AMI ID, account ID, région, VPC ID, subnet ID, IAM role ARN, IAM instance profile ARN, EC2 instance ID, role tag et IAM principal ARN.

Bien entendu, Vault peut se baser sur une ou plusieurs de ces informations. Notez bien que si vous possédez un AutoScaling Group, les valeurs comme l’instance ID sont variables et doivent donc être mises à jour côté Vault si vous l’avez spécifié.

Concernant la partie IAM, celle-ci consiste à identifier un service (qu’il soit sur EC2 ou autre) ayant des identifiants IAM a s’authentifier sur Vault. L’authentification IAM touche donc plus de services que celle orientée uniquement sur les instances EC2.

Cas d’usage

Utile dans le cas où les méthodes telles que AppRole ou TLS certificates n’apportent pas un niveau de sécurité suffisant dans un contexte cloud (ex: secret dans le userdata) ou encore pour les workflow qui ne sont pas complètement automatiséq. Cette méthode est idéale afin de récupérer les secrets au provisionning sans pour autant les exposer aux administrateurs des plateformes cloud public.

A retenir

• Le Vault doit avoir des droits sur le compte où il doit faire les opérations.
• Le Vault doit avoir des informations des applications (ex: subnet ID) et mettre la configuration en conséquence. Ce qui peut nécessiter une charge opérationnelle lourde côté administrateur Vault si celle-ci n’est pas automatisée.
• Le cross-account (Vault hébergé dans un account et l’application dans un autre account) peut rendre la configuration complexe.

Kubernetes

Cette méthode se base sur le fait que l’application soit contenerisée sous Kubernetes. Pour identifier l’application, Vault se base sur le Kubernetes Service Account Token (le token JWT), le service account name et enfin le namespace. Ce qui implique donc que Vault doit avoir les droits côté Kubernetes TokenReview API pour vérifier ses informations.

Usage

Cette méthode permet de garantir que seule l’application est en droit d’accéder a ses secrets (dans la même logique que dans la méthode AppRole). Celle-ci est donc la plus simple pour l’ensemble des application contenerisées sous Kubernetes.

Pour simplifier l’intégration avec Vault, il est recommandé d’incorporer un script permettant de s’authentifier et récupérer les secrets applicatifs au démarrage du container.

A retenir

• Vault doit nécessiter des droits RBAC pour avoir un accès au Kubernetes TokenReview API.
• Chaque application doit avoir un Service Account.
• Dépendance forte à Kubernetes contrairement aux authentifications comme AppRole ou TLS certificates

Pour aller plus loin

Comme vous pouvez le voir, nous avons fait un grand tour d’horizon de l’ensemble des méthodes d’authentification aussi appelées “Auth Backend”. Cependant, nous n’avons pas abordé deux méthodes particulières: Okta et JWT/OIDC que je vous invite à regarder par vous même. Sachant que ce sont des nouvelles méthodes que je n’ai pas pu tester, je ne pourrais pas apporter mon retour d’expérience.

Au vu de l’ensemble de ses méthodes, il est important de se dire que chacune d’entre elles a son atout et qu’il peut être intéressant de les mixer entre elles. Une bonne méthode est d’introduire une politique d’authentification au Vault en fonction du contexte: applicatif (workflow automatisé ou non), personne physique (Administrateur ou client), environnement (cloud ou on-premises), etc.

Enfin, un Vault Agent a vu le jour dans la dernière version en date de cet article (0.10.4). Vault Agent (avec auto auth) permet de simplifier grandement l’authentification des applications sans se pencher sur l’API Vault ou sans passer par Vault CLI tout en protégeant le stockage du Token. Je vous invite à voir plus en détail cette partie afin d’intégrer au mieux vos choix en terme de méthode d’authentification.