Gérer vos secrets avec Vault – Partie 2/2

2.2.2 Générer des identifiants de connexion

1. Récupérez les identifiants générés par Vault dans le MySQL :

2. Connectez-vous au MySQL pour tester le couple username/password :

Pour utiliser ces identifiants tournants, des modifications dans votre application seront nécessaires : en faisant une requête REST directement (exemple ci-dessous avec curl) ou en utilisant une bibliothèque dédiée au langage (hvac pour python, Spring Cloud Vault pour java, etc.) :

Si d’autres modules à explorer existent, il n’est pas possible de tous les traiter ici. Lorsque l’on centralise les secrets, le plus important est d’en contrôler strictement les accès, regardons la procédure à suivre.

3. Contrôler l’accès à vos secrets

Il y a deux techniques essentielles pour contrôler l’accès aux secrets : les tokens avec leurs modules d’authentification et les politiques de droit.

3.1 Comprendre les tokens

Les mécanismes d’authentification reposent sur le composant « token ». Il est représenté par un uuid, créé aléatoirement. Il est rattaché à une ou plusieurs politiques de droits, une structure de données qui permettent de les représenter sous la forme d’arbre ainsi que d’autres propriétés (durée de vie, nombre d’utilisation…). Il est plus pratique et flexible d’utiliser un module d’authentification que de créer des tokens manuellement, car il le fera pour vous. Néanmoins, il est important d’en comprendre le fonctionnement, car ils sont toujours manipulés.

La première manipulation de token est l’authentification que nous avons utilisée pour administrer Vault :

Une fois authentifié(e), on peut consulter les propriétés de son token :

Enfin, si on souhaite les créer, les renouveler et les détruire, découvrez cinq manipulations courantes.

3.1.1. 5 manipulations courantes de tokens

1. Comment créer un token « root » ? Ce type de token n’expire jamais. Il doit être créé pour un nombre restreint de personnes et ne jamais être mis dans une application.

2. Comment créer une hiérarchie de token ? En créant initialement la racine avec un token orphelin. Par défaut, le token est renouvelable. Il a une durée de vie fixée à « default_lease_ttl ».

3. Comment créer un token avec une durée de vie limitée à 10 heures, renouvelable jusqu’à « default_lease_ttl »?

4. Comment renouveler un token ? Vous devez le renouveler avant son expiration.

5. Comment révoquer un token ? Soit avec sa valeur, soit via son accesseur afin de révoquer des droits sans les avoir.

Tous les tokens possèdent une ou plusieurs « policy » qui déterminent les politiques d’accès aux données. Créons en maintenant pour nos besoins.

3.2 Politique d’accès

Ils déterminent les permissions sur les secrets ou l’administration : lecture et écriture des différentes branches. Une permission se configure à l’aide de la syntaxe HCL ou json.

On décrit le chemin d’accès, avec éventuellement des jokers, puis leurs politiques et/ou leurs capacités. Une politique est un ensemble de capacités. Par défaut, il existe deux politiques de droits, lisibles ainsi :

Par défaut rien n’est autorisé. C’est la politique « default » qui permet de manipuler son propre token et son cagibi personnel (cubbyhole) : elle est automatiquement appliquée sauf à root qui a tous les droits.

3.2.1 Les droits pour votre script apache SSL

1. Définissez une politique pour que votre script apache ait accès en lecture au mot de passe SSL et appliquez-la avec la commande policy-write :

2. Ajoutez une politique pour administrer ces secrets :

On peut faire des politiques plus complexes comme supprimer n’importe quel token, verrouiller les secrets en cas d’intrusion et contrôler les politiques de sécurité :

Ici, l’utilisation du droit sudo pour le scellement est nécessaire, car il est réservé à « root ».

3.2.2 Les droits pour votre MySQL

1. Donnez les droits de configuration sur le module MySQL à vos administrateurs.

2. N’oubliez pas de protéger tous les accès au compte MySQL créé (écriture, lecture…).

Les politiques de droits sont dynamiques. Elles sont lues à chaque requête : inutile de recréer un token. De plus, on peut donner des droits sur des chemins qui n’existent pas encore.

Nous l’avons vu, manipuler les tokens est une tâche fastidieuse. Pour y palier, des modules existants génèrent, gèrent et appliquent les politiques de droit aux tokens.

3.3 Les modules d’authentification

Ils sont nombreux, du GitHub au LDAP d’entreprise. Présentons le module « userpass » pour authentifier des personnes et le module « approle », orienté machines/applications.

3.3.1 Authentifiez des personnes

1. Activez le module une première fois et créez des utilisateurs adaptés à vos précédentes politiques de droits (un échantillon ci-dessous).

2. Authentifiez-vous à l’aide de la commande auth et vos couples utilisateurs/mots de passe pour recevoir votre token.

L’authentification des personnes réussie, il s’agit de faire de même avec les applications/machines.

3.3.2 Authentifier des machines et des applications

Le module « approle » permet de créer des rôles pour vos machines et vos applications : on l’utilisera pour authentifier notre script pour apache.

1. Activez le module une seule fois :

2. Créez le rôle « web_projeta » sur lequel on associe notre politique de droits « lecture_web » et on y affecte une restriction d’IP pour renforcer la sécurité.

3. Récupérez l’identifiant de votre rôle :

4. Récupérez votre « secret-id » qui est une sécurité supplémentaire. Elle associe à un rôle, un uuid confidentiel. Cela empêche la fuite de secret, lorsque l’on connaît juste le nom de l’application.

5. Modifiez le script apache ainsi :

Vous pouvez utiliser le même principe pour vos applications. Maintenant pour faire face à un incident de sécurité, on doit auditer notre gestionnaire de secret.

4. Gardez le contrôle

Pour détecter toutes activités anormales, il faut l’interconnecter avec un produit de surveillance qui est facilité par le format json des logs (Elasticsearch/watch) :

Rassurez-vous, toutes les actions sont loggées avec des tokens et les secrets hachés en SHA256.

Conclusion

Vault est un outil complet et moderne adapté à tout type d’architecture moyennant quelques modifications logicielles. La mise à disposition du code source et les audits réalisés par des professionnels sont rassurants.
C’est un logiciel récent qui évolue, il est donc à installer avec un suivi régulier des mises à jour. De plus, on pourrait lui reprocher un manque de fonctionnalités pour les entreprises (HSM et interface d’administration) absentes dans la version communautaire. Néanmoins, il offre de nombreuses fonctionnalités puissantes adaptées à tous.

Denis Mortreux

Retrouvez cet article (et bien d’autres) dans Linux Pratique n°100, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Laisser un commentaire