Comment gérer en toute sécurité les secrets avec HashiCorp Vault sur Ubuntu 20.04

De Get Docs
Aller à :navigation, rechercher

Introduction

Vault est un outil open source qui fournit un moyen sûr et fiable de stocker et de distribuer des secrets tels que des clés d'API, des jetons d'accès et des mots de passe. Des logiciels comme Vault peuvent être d'une importance cruciale lors du déploiement d'applications nécessitant l'utilisation de secrets ou de données sensibles.

Dans ce didacticiel, vous allez :

  • Installez Vault et configurez-le en tant que service système
  • Initialiser un magasin de données chiffré sur disque
  • Stockez et récupérez une valeur sensible en toute sécurité via TLS

Avec quelques règles supplémentaires en place, vous pourrez utiliser Vault pour gérer en toute sécurité les données sensibles de vos diverses applications et outils.

Comme pour tout service qui gère des informations sensibles, vous devriez envisager de lire la documentation supplémentaire concernant les bonnes pratiques de déploiement de Vault avant de l'utiliser dans un environnement de production. Par exemple, le guide de renforcement de la production de Vault couvre des sujets tels que les stratégies, les jetons racine et l'audit.

Conditions préalables

Avant de commencer ce guide, vous aurez besoin des éléments suivants :

Remarque : Vault génère un certificat TLS auto-signé lorsque vous installez le package pour la première fois. Si vous n'avez pas de nom de domaine ou de certificat TLS à utiliser avec Vault mais que vous souhaitez suivre les étapes de ce didacticiel, vous pouvez ignorer la vérification TLS en ajoutant l'indicateur -tls-skip-verify aux commandes de ce didacticiel, ou en définissant la variable d'environnement VAULT_SKIP_VERIFY.

Cette option ne convient que pour tester Vault et ne doit pas être utilisée dans un environnement de production.


Étape 1 - Installation du coffre-fort

HashiCorp fournit Vault en tant que package Debian/Ubuntu typique, nous allons donc suivre les étapes normales d'ajout de leur référentiel de packages à la liste des sources de packages de notre serveur :

Tout d'abord, ajoutez la clé GPG de Hashicorp à votre gestionnaire de packages, afin que votre système fasse confiance à leurs référentiels de packages :

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -

Ajoutez ensuite le référentiel lui-même à votre liste de sources de packages, afin qu'il soit vérifié pour les mises à jour régulières :

sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"

Installez ensuite le package :

sudo apt install vault

Vous pouvez maintenant utiliser la commande vault. Essayez de vérifier la version de Vault pour vous assurer qu'elle fonctionne.

vault --version
OutputVault v1.8.5 (647eccfe0bd5817bdd8628f3c3171402dfc8a8fc)

L'exécutable Vault est installé sur votre serveur, l'étape suivante consiste donc à le configurer pour qu'il s'exécute en tant que service système.

Étape 2 - Configuration du coffre-fort

L'installation du package Vault crée automatiquement un utilisateur vaultvault sur votre système et configure un service système pour exécuter Vault en arrière-plan. Nous devons apporter quelques modifications à sa configuration par défaut afin d'utiliser les certificats HTTPS générés par Let's Encrypt.

Remarque : Dans ce didacticiel et par défaut, Vault utilise le backend du système de fichiers [1] pour stocker les secrets chiffrés sur le système de fichiers local sur /opt/vault. Cela convient aux déploiements locaux ou à serveur unique qui n'ont pas besoin d'être répliqués. D'autres backends Vault, tels que le backend Consul, stockeront les secrets chiffrés au repos dans un magasin clé/valeur distribué.


La configuration par défaut de Vault est stockée dans /etc/vault.d/vault.hcl. Vous utiliserez ce fichier pour contrôler diverses options dans Vault, telles que l'emplacement de stockage des secrets chiffrés.

Ouvrez vault.hcl en utilisant nano ou votre éditeur de texte préféré.

sudo nano /etc/vault.d/vault.hcl

Trouvez la section listener "tcp" du fichier sous #HTTPS listener qui contient ce bloc. Si vous utilisez nano, vous pouvez appuyer sur Ctrl+W puis entrer listener “tcp” pour trouver directement cette ligne :

/etc/vault.hcl

...
#HTTPS listener
...
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/tls.crt"
  tls_key_file  = "/opt/vault/tls/tls.key"
...
}

Modifiez les lignes tls_cert_file et tls_key_file pour qu'elles pointent vers votre certificat Let's Encrypt et vos fichiers de clé. N'oubliez pas de substituer votre propre nom de domaine à la place de la partie en surbrillance your_domain de chaque ligne.

/etc/vault.hcl

listener "tcp" {
...
  tls_cert_file = "/etc/letsencrypt/live/your_domain/fullchain.pem"
  tls_key_file = "/etc/letsencrypt/live/your_domain/privkey.pem"
}

Remarque : Vous devez également remplacer address = "0.0.0.0:8200" par address = “127.0.0.1:8200” pour empêcher les connexions externes à ce serveur pour le moment. 127.0.0.1 est une adresse réservée pour localhost uniquement. Cela permet de s'assurer que le service n'est pas exposé à l'Internet public avant d'avoir été correctement sécurisé. Vous pouvez le mettre à jour plus tard, mais pour l'instant, ce changement de configuration nous permettra d'utiliser la commande vault et de résoudre correctement le nom de domaine sécurisé HTTPS.


Enregistrez et fermez le fichier. Si vous utilisez nano, appuyez sur Ctrl+X, puis Y lorsque vous êtes invité à enregistrer le fichier, et Enter pour confirmer.

Ensuite, l'utilisateur du système vault a également besoin d'une autorisation pour lire ces certificats. Par défaut, ces certificats et clés privées ne sont accessibles que par root. Pour les rendre disponibles en toute sécurité, nous allons créer un groupe spécial appelé pki pour accéder à ces fichiers. Nous allons créer le groupe puis y ajouter l'utilisateur vault.

sudo groupadd pki

Mettez à jour les autorisations sur les deux répertoires dans le répertoire /etc/letsencrypt pour permettre aux membres du groupe pki de lire le contenu.

sudo chgrp -R pki /etc/letsencrypt/archive
sudo chgrp -R pki /etc/letsencrypt/live
sudo chmod -R g+rx /etc/letsencrypt/archive
sudo chmod -R g+rx /etc/letsencrypt/live

Ajoutez ensuite l'utilisateur vault au groupe pki. Cela accordera à Vault l'accès aux certificats afin qu'il puisse traiter les demandes en toute sécurité via HTTPS.

sudo usermod -a -G pki vault

Comme dernière étape pour plus de commodité, ajoutez une règle dans /etc/hosts pour diriger les requêtes vers Vault vers localhost.

Remplacez your_domain dans la commande suivante par le domaine pour lequel vous avez acquis le certificat Let's Encrypt :

echo 127.0.0.1 your_domain.com | sudo tee -a /etc/hosts

Cette commande ajoute la ligne 127.0.0.1 your_domain.com à /etc/hosts afin que toutes les requêtes HTTP que vous faites sur votre serveur Vault à your_domain.com ignorent le DNS et soient envoyées directement à localhost. .

Une fois le service Vault configuré et le fichier de configuration Vault terminé, nous sommes maintenant prêts à démarrer Vault et à initialiser le magasin de secrets.

Étape 3 - Initialisation du coffre-fort

Lorsque vous démarrez Vault pour la première fois, il n'est pas initialisé, ce qui signifie qu'il n'est pas prêt à recevoir et à stocker des données. Dans cette section du didacticiel, vous allez démarrer le serveur Vault, puis l'initialiser avec un ensemble de clés secrètes qui seront utilisées pour desceller (ouvrir) les magasins secrets de Vault.

La première fois que vous démarrez Vault, le backend qui stocke réellement les secrets chiffrés n'est pas non plus initialisé. Démarrez le service système Vault pour initialiser le backend et commencer à exécuter Vault lui-même.

sudo systemctl start vault.service

Vous pouvez exécuter une vérification rapide pour confirmer que le service a démarré avec succès.

sudo systemctl status vault.service

Vous devriez recevoir une sortie semblable à celle-ci :

Output● vault.service - "HashiCorp Vault - A tool for managing secrets"
     Loaded: loaded (/lib/systemd/system/vault.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2021-11-16 21:55:13 UTC; 22s ago
       Docs: https://www.vaultproject.io/docs/
   Main PID: 104207 (vault)
      Tasks: 7 (limit: 1137)
     Memory: 179.3M
     CGroup: /system.slice/vault.service
             └─104207 /usr/bin/vault server -config=/etc/vault.d/vault.hcl

La sortie de cette commande doit inclure plusieurs informations sur le service en cours d'exécution, telles que son ID de processus et l'utilisation des ressources. Assurez-vous que la ligne suivante est incluse dans la sortie, ce qui indique que le service s'exécute correctement.

Output. . .
Active: active (running)
. . .

Si le service n'est pas actif, consultez les lignes de journal d'accompagnement à la fin de la sortie de la commande pour voir la sortie de Vault, ce qui peut aider à identifier les problèmes.

Ensuite, nous allons définir une variable d'environnement pour indiquer à la commande vault comment se connecter au serveur Vault. À l'Étape 1, vous avez configuré Vault pour qu'il n'écoute que sur l'interface de bouclage locale. Définissez donc la variable d'environnement VAULT_ADDR sur le point de terminaison HTTPS local.

export VAULT_ADDR=https://your_domain:8200

La commande vault peut maintenant communiquer avec le démon. Notez que la définition du nom d'hôte réel au lieu de simplement localhost ou 127.0.0.1 est nécessaire pour valider correctement le certificat HTTPS.

Confirmez que le serveur de coffre-fort est dans un état non initialisé en vérifiant son état.

vault status

Le serveur doit renvoyer une sortie afin que vous puissiez dire qu'il fonctionne mais qu'il n'est pas encore initialisé.

Key Value
--- -----
Seal Type shamir
Initialized false
Sealed true
Total Shares 0
Threshold 0
Unseal Progress 0/0
Unseal Nonce n/a
Version 1.8.5
Storage Type file
HA Enabled false

Il y a deux informations que Vault exposera au moment de l'initialisation qui ne seront pas disponibles à tout autre moment :

  • Jeton racine initial. Cela équivaut aux autorisations root sur votre déploiement Vault, ce qui permet la gestion de toutes les stratégies, montages et secrets Vault.
  • Desceller les clés. Ceux-ci sont utilisés pour desceller Vault lorsque le démon démarre, ce qui permet au démon Vault de déchiffrer le magasin de secrets principal.

Plus précisément, le processus de descellement de Vault déchiffre le backend à l'aide d'une clé formée de partages de clés. Lorsque vous initialisez Vault pour la première fois, vous pouvez choisir le nombre de clés de descellement à créer et le nombre nécessaire au moment du descellement pour réussir à desceller Vault. Pour en savoir plus sur le mécanisme de scellement de Vault, vous pouvez vous référer à la Documentation Vault.

Une configuration typique pour les paramètres de descellement serait de créer trois clés et d'exiger au moins deux de ces clés au moment du descellement. Cela permet aux partages de clés importants d'être séparés et stockés dans des emplacements distincts pour s'assurer qu'en compromettre un n'est pas suffisant pour desceller Vault.

En d'autres termes, chaque fois que Vault est démarré, au moins deux clés de descellement seront nécessaires pour rendre le service disponible et prêt à l'emploi. Tant qu'ils sont scellés, les fichiers qui stockent les valeurs secrètes réelles resteront cryptés et inaccessibles.

Initialisez le coffre-fort avec trois clés de descellement à l'aide de l'option -key-shares=3 et exigez au moins deux clés pour desceller le coffre-fort avec l'indicateur -key-threshold=2 ::

vault operator init -key-shares=3 -key-threshold=2

Vous recevrez une sortie comme celle-ci :

OutputUnseal Key 1: eZcJeydRrqeSMZ1zTN+VVll9TFT2KvJy7VlnxUgtvuz5
Unseal Key 2: ntmqCKq8rgNnKT1YSLCjVmCCZBAA3NwUeqxIyRpYD4Wm
Unseal Key 3: 3FK1+Hsorh4p8/L9mki3VskaEU2eQhLqGOI/pJkTHMbx

Initial Root Token: s.hY0ieybfDqCadz7JpL88uO3x

Assurez-vous de sauvegarder chaque jeton de descellement et le jeton racine initial de manière sécurisée. Vous ne pourrez plus récupérer ces clés et ce jeton racine. Par exemple, une option serait de stocker une clé de descellement dans un gestionnaire de mots de passe, une autre sur une clé USB et une autre dans un fichier crypté GPG.

Si vous examinez à nouveau vault status, l'état Initialized sera maintenant réglé sur true, et les valeurs Total Shares et Threshold refléteront le nombre de fragments de clé et nombre minimum de clés dont vous aurez besoin pour desceller le coffre-fort.

vault status
Output. . .
Initialized     true
Sealed          true
Total Shares    3
Threshold       2
Unseal Progress 0/2
. . .

Notez que la ligne Unseal Progess affiche la valeur 0/2. Commencez à desceller Vault en utilisant vos jetons de descellement nouvellement créés. Exécutez la commande vault operator unseal et saisissez l'une de vos clés lorsque vous y êtes invité :

vault operator unseal

La commande demandera un jeton de descellement :

OutputKey (will be hidden):

Après l'avoir saisie, la sortie de la commande indiquera que le descellement est en cours, mais nécessite encore une clé de descellement supplémentaire avant que Vault soit prêt à être utilisé.

OutputKey                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       3
Threshold          2
Unseal Progress    1/2
Unseal Nonce       0f3a328b-e0c6-6294-d6a2-56da49271dff
Version            1.8.5
Storage Type       file
HA Enabled         false

Remarquez comment la ligne Unseal Progress 1/2 a changé dans la sortie. Exécutez à nouveau la commande unseal.

vault operator unseal

Et entrez une clé différente de celle que vous avez déjà utilisée :

OutputKey (will be hidden):

La sortie de la commande indique que le processus de descellement s'est terminé avec succès.

OutputKey             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    3
Threshold       2
Version         1.8.5
Storage Type    file
Cluster Name    vault-cluster-3042c7bc
Cluster ID      c3e9d814-cf2a-2901-f0e4-ebc52d29e5cc
HA Enabled      false

Vault est maintenant descellé et prêt à l'emploi. Ces étapes de descellement sont nécessaires chaque fois que Vault est démarré ou redémarré.

Cependant, le descellement est un processus distinct de l'interaction normale avec Vault (telle que la lecture et l'écriture de valeurs), qui sont authentifiées par des tokens. Dans les étapes suivantes, nous allons créer les jetons d'accès et les règles nécessaires pour stocker les valeurs secrètes et lire/écrire dans des chemins spécifiques dans Vault.

Étape 4 - Secrets de lecture et d'écriture

Il existe plusieurs backends secrets que vous pouvez utiliser avec Vault, mais pour cet exemple, nous utiliserons le backend secret kv. Ce backend stocke des paires clé/valeur simples dans Vault. Cependant, il n'est pas activé par défaut.

Dans cette section du didacticiel, vous activerez le backend secret kv, puis apprendrez à lire et à écrire des secrets dessus.

Tout d'abord, enregistrez le jeton racine généré précédemment dans une variable shell pour en faciliter l'utilisation.

root_token=your_root_token_here

Ensuite, lors de l'authentification avec le jeton racine, activez le backend kv :

VAULT_TOKEN=$root_token vault secrets enable kv

Vous recevrez une sortie comme celle-ci si la commande réussit :

OutputSuccess! Enabled the kv secrets engine at: kv/

Vous pouvez ensuite vérifier qu'il a été ajouté à votre liste locale de backends secrets disponibles :

VAULT_TOKEN=$root_token vault secrets list

Vous devriez recevoir une sortie comme celle-ci :

OutputPath          Type         Accessor              Description
----          ----         --------              -----------
cubbyhole/    cubbyhole    cubbyhole_abc1631b    per-token private secret storage
identity/     identity     identity_631fe262     identity store
kv/           kv           kv_4d5855c8           n/a
sys/          system       system_79b13f2f       system endpoints used for control, policy and debugging

Notez la ligne en surbrillance qui indique que le nouveau backend kv est activé. Maintenant, nous pouvons stocker des données avec ce backend.

VAULT_TOKEN=$root_token vault write kv/message value=mypassword

Dans cette commande, le préfixe kv/ en surbrillance indique que nous écrivons sur le backend kv monté sur le chemin kv, et nous stockons la clé value au chemin message avec la valeur mypassword. Nous avons utilisé le jeton racine, qui a des privilèges de superutilisateur, pour écrire le secret générique.

Vérifiez le secret que vous avez créé à l'aide de la commande vault read :

VAULT_TOKEN=$root_token vault read kv/message

Vous devriez recevoir une sortie comme celle-ci, avec le contenu du secret que vous avez créé :

OutputKey                 Value
---                 -----
refresh_interval    768h
value               mypassword

Cependant, la création, la lecture et l'interaction avec Vault à l'aide du jeton racine uniquement ne sont pas sécurisées, évolutives dans un environnement d'équipe et ne permettent pas un contrôle d'accès précis aux secrets. Dans la section suivante, vous apprendrez à définir des règles et à créer des jetons d'accès supplémentaires pour restreindre la manière dont les utilisateurs peuvent interagir avec Vault.

Étape 5 - Création d'une politique d'autorisation

Dans un scénario réel, vous pouvez stocker des valeurs telles que des clés d'API ou des mots de passe que des outils externes peuvent consommer. Bien que vous puissiez relire la valeur secrète à l'aide du jeton racine, il est illustratif de générer un jeton moins privilégié avec des autorisations en lecture seule sur notre secret unique.

Dans cette section du didacticiel, vous allez créer une Politique Vault qui appliquera un accès en lecture seule aux secrets. Pour créer la stratégie, vous devez modifier un fichier, puis le charger dans Vault à l'aide de la commande vault policy.

Pour commencer à créer une stratégie, ouvrez un fichier appelé policy.hcl à l'aide de nano ou de votre éditeur préféré :

nano policy.hcl

Remplissez le fichier avec la stratégie Vault suivante, qui définit l'accès en lecture seule au chemin secret : :

politique.hcl

path "kv/message" {
     capabilities = ["read"]
}

Enregistrez et fermez le fichier, puis écrivez cette stratégie dans Vault. La commande suivante chargera le fichier policy.hcl dans Vault et créera une stratégie nommée message-readonly avec la capacité de lecture seule

VAULT_TOKEN=$root_token vault policy write message-readonly policy.hcl

Ensuite, créez un jeton que vous utiliserez pour un accès en lecture seule à Vault. Ajoutez l'indicateur -policy=”message-readonly” à la commande vault token create pour utiliser la nouvelle stratégie que vous avez créée :

VAULT_TOKEN=$root_token vault token create -policy="message-readonly"

La sortie ressemblera à ceci :

OutputKey                  Value
---                  -----
token                your_token_value
token_accessor       your_token_accessor
token_duration       768h0m0s
token_renewable      true
token_policies       ["default" "message-readonly"]
identity_policies    []
policies             ["default" "message-readonly"]

Enregistrez la valeur your_token_value en surbrillance dans une variable d'environnement appelée app_token :

app_token=your_token_value

Vous pouvez utiliser la valeur de app_token pour accéder aux données stockées dans le chemin kv/message (et aucune autre valeur dans Vault).

VAULT_TOKEN=$app_token vault read kv/message
OutputKey                     Value
---                     -----
refresh_interval        768h0m0s
value                   mypassword

Vous pouvez également tester que ce jeton non privilégié ne peut pas effectuer d'autres opérations, telles que la liste des secrets dans Vault.

VAULT_TOKEN=$app_token vault list kv/
OutputError reading kv/: Error making API request.

URL: GET https://your_domain:8200/v1/secret?list=true
Code: 403. Errors:

* 1 error occurred:
    * permission denied

Cela vérifie que le jeton d'application moins privilégié ne peut pas effectuer d'actions destructrices ni accéder à d'autres valeurs secrètes en dehors de celles explicitement indiquées dans sa stratégie Vault. Si vous souhaitez continuer à utiliser le jeton en lecture seule, assurez-vous de l'enregistrer dans un endroit sûr pour une utilisation future.

Conclusion

Dans cet article, vous avez installé, configuré et déployé Vault sur Ubuntu 20.04. Vous avez également créé une clé fragmentée pour desceller Vault, activé le magasin de secrets backend kv et défini une règle de lecture seule pour limiter la façon dont un utilisateur peut interagir avec les secrets Vault.

Bien que ce didacticiel n'ait montré que l'utilisation d'un jeton non privilégié, la documentation Vault contient d'autres exemples de moyens supplémentaires de stocker et d'accéder aux secrets ainsi que des méthodes d'authentification alternatives.

Ces instructions ont montré comment déployer et utiliser certaines des fonctionnalités principales de Vault. Vos besoins peuvent nécessiter d'autres changements de configuration et des politiques plus complexes. Assurez-vous de lire la documentation Vault et apportez les modifications de configuration appropriées à vos besoins. Certaines modifications prêtes pour la production peuvent inclure :

  • Génération de jetons moins privilégiés pour une utilisation quotidienne. Les politiques spécifiques que ces jetons doivent utiliser dépendent de vos cas d'utilisation spécifiques, mais l'exemple app_token de ce didacticiel illustre comment vous pouvez créer des jetons et des politiques à privilèges limités.
  • Si vous déployez Vault dans le cadre d'un service qui sera utilisé par une équipe, initialisez Vault avec des clés de descellement pour chaque membre de l'équipe. Cette approche peut garantir que le stockage de Vault n'est déchiffré que lorsque plusieurs membres de l'équipe participent au processus.