debian12Vaultsecret manager
Installer et utiliser Vault - Secret Manager
Ce guide présente, comment installer et utiliser Vault Community (Free), un manager de secret édité par HashiCorp.
Plus précisément il s'agit de la version Open source de Vault.
La différence entre la version Community et Enterprise est présentée: ici
Pourquoi utiliser un gestionnaire de secret?
Pour cacher un secret... <.<
> Merci, \o
On peut s'en servir pour toutes informations que l'on souhaite cacher, comme une clé d'API par exemple.
En développement web, il est d'usage d'utiliser des variables d'environnement initialiser par un fichier .env
C'est pas mal et suffisant pour certains cas. Mais en cas de hack sur le serveur, notamment en mutualisé, les clefs finissent dans la nature.
Utiliser un gestionnaire de secret permet de ne pas avoir de clé API hardcoded et nous laisse un délai supplémentaire pour "changer la serrure" en cas de compromission du serveur.
On peut l'utiliser pour réaliser des authentification à des services distants, il y a pleins de cas possible d'utilisation.
Installation
Vault est compatible: macOS, Windows, Linux (Ubuntu/Debian - CentOS/RHEL - Fedora - Amazon Linux - Homebrew), FreeBSD, NetBSD, OpenBSD, Solaris.
Comme d'habitude, mon cas personnel traitera de Debian. Pour les autres versions, la doc est très explicative.
# installation de Vault sur Debian
# requirement GPG
sudo apt update && sudo apt install gpg wget
# gestion des clefs
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
gpg --no-default-keyring --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg --fingerprint
# ajout du repo HashiCorp
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
#installation
sudo apt update && sudo apt install vault
# verification de l'installation on execute vault
vault
Principe de fonctionnement
Vault est très versatile, via son système de plugins et d'engines, Vault peut interagir avec tous un tas de services différents.
Vault stock les secrets de manière chiffré, le mécanisme de stockage ne "voit" jamais les données non chiffrées.
Il dispose de plusieurs 'moteurs' de secrets qui sont capable d’interagir avec différents services.
Le plus basique est kv pour key/value.
Vault dispose d'autres 'engine': Kubernetes, GitHub, JWT, Databases, SSH, OTP,...
Cela permet à vault d’interagir de manière physique avec un système, par exemple pour une base de données.
Mais aussi des environnement spécifiques comme: AWS IAM
Pour l'authentification Vault utilise le principe des tokens.
Un token permet de s'authentifier tandis que les Policies permettent de définir des autorisations, un contrôle d'accès.
Le principe du secret
Sous sa forme la plus basique c'est une paire de clé/valeur.
S'entraîner à utiliser Vault CLI en mode DEV
Je ne peux que conseiller de commencer par utiliser Vault en mode CLI dans l'environnement de test fournit avec Vault. Un tutoriel est disponible ici.
Aussi vous pouvez suivre directement le tutoriel officiel, il est très bien fait, accompagné de vidéo démonstrative.
Cela permet de se familiariser avec l'outil et de comprendre les grandes lignes.
Écrire un secret
Sous cette forme: vault kv put path_of_the_secret key=value
On peut écrire plusieurs paires en une fois pour un meme path donnée.
vault kv <b>put</b> secret/hello foo=world
A cause du log de l'historique du shell, il est préférable d'utiliser des fichiers à la place.
Lire des secrets
vault kv get path_of_the_secret
vault get secret/hello
Supprimer des secrets
vault kv delete path_of_the_secret
vault delete secret/hello
La liste des commandes:
- delete <== Deletes versions in the KV store
- destroy <== Permanently removes one or more versions in the KV store
- enable-versioning <== Turns on versioning for a KV store
- get <== Retrieves data from the KV store
- list <== List data or secrets
- metadata <== Interact with Vault's Key-Value storage
- patch <== Sets or updates data in the KV store without overwriting
- put <== Sets or updates data in the KV store
- rollback <== Rolls back to a previous version of data
- undelete <== Undeletes versions in the KV store
A savoir, Vault est capable de gérer des secrets dynamique, ils sont générés/utilisée à un instant T, leur nature volatile est un atout de sécurité.
C'est une utilisation plus avancée qui ne sera pas vue en détail dans cet article. Un tuto est disponible dans la documentation officielle.
Mise en service de Vault
Ok, on a fait joujou en mode DEV. Mais nous on veux un service de gestionnaire de secret.
Configuration
Ici, il faut adapter au besoin, est-ce qu'on a besoin d'un accès extérieur: address = "0.0.0.0:8200" ou pas "127.0.0.1:8200"
Le fichier de config: /etc/vault.d/vault.hcl
...
#HTTPS listener
...
listener "tcp" {
address = "0.0.0.0:8200"
tls_cert_file = "/etc/letsencrypt/live/domain.tld/fullchain.pem"
tls_key_file = "/etc/letsencrypt/live/domain.tld/privkey.pem"
...
}
Pour les certificats, il faut penser à donner les bonnes permissions sur les répertoires.
Étant "rookie", je n'ai pas le recule et l'expérience nécessaire pour faire 'mieux' ici.
Merci, de me contacter si vous pensez que la méthode est mauvaise et/ou perfectible 🙇🏻.
On va créer un groupe 'pki' qui sera propriétaire du répertoire des certificats et ajouter l'utilisateur Vault à ce groupe.
# création du groupe
sudo groupadd pki
# changement du groupe pour les certifs.
sudo chgrp -R pki /etc/letsencrypt/archive
sudo chgrp -R pki /etc/letsencrypt/live
# permission de lecture/execution pour le groupe
sudo chmod -R g+rx /etc/letsencrypt/archive
sudo chmod -R g+rx /etc/letsencrypt/live
# ajout de l'utilisateur vault au group
sudo usermod -a -G pki vault
Initialisation
Il faut maintenant mettre en place le service et initialiser Vault
# start le service
sudo systemctl start vault.service
# check si tout est ok
sudo systemctl status vault.service
● vault.service - "HashiCorp Vault - A tool for managing secrets" Loaded: loaded (/lib/systemd/system/vault.service; enabled; preset: enabled) Active: active (running) since Mon 2024-09-16 18:52:26 UTC; 5s ago
On passe à la phase d'initialisation, Vault va générer la clé de chiffrement, les clés de 'déverrouillage' (seal/unseal) et créer le root token.
Il est nécessaire de créer un variable d'environnement, à adapter suivant vos besoins: 127.0.0.1:port ou domain.tld:port
export VAULT_ADDR='https://127.0.0.1:8200'
Afin de voir si la variable est bien prise en comte:
vault status
Chercher la valeur: Initialized false dans le retour de la commande:
Key Value
--- -----
Seal Type shamir
Initialized false
Sealed true
Total Shares 0
Threshold 0
Unseal Progress 0/0
Unseal Nonce n/a
Version 1.17.5
Build Date 2024-08-30T15:54:57Z
Storage Type file
HA Enabled false
On va maintenant initialiser Vault de la manière suivante:
- Générer trois clés de 'déverrouillage'
- Paramétrer de sorte que deux clés soient nécessaire pour 'déverrouiller'
Vault affichera les clés de 'déverrouillage' et le root token.
Notez impérativement ces informations en lieux sûre.
vault operator init -key-shares=3 -key-threshold=2
Si tout est ok vous avez le retour suivant:
Unseal Key 1: --------------------------------------------
Unseal Key 2: --------------------------------------------
Unseal Key 3: --------------------------------------------
Initial Root Token: -------------------------
Vault est initialisé et automatiquement 'verrouillé'
J'ai pas vraiment la raison.
La chose qui me 'tic' c'est le https et le port par défaut 8200
Hors, qui dit SSL dit port 443, soit quelques chose du genre domain.tld:443
Il faut certainement mettre une autre configuration... Si vous avez une idée?
Du coup, je suis passé directement par l'interface UI.
Ce n'est pas du tout recommandé de faire ainsi
Vos premiers secrets - policy
Il ne reste plus qu'à enregistré vos premiers secret, soit en CLI comme vu au-dessus ou via l'UI.
Pour acceder aux secrets il est important de le faire par un autre utilisateur que le root token.
Pour cela il faut créer une Policy qui va décrire les autorisations minimale que l'on souhaite accorder.
Exemple 'rapide' en cli:
vault login
vault secrets enable -path=secret kv
vault kv put secret/le_path key=value other_key=other_value
#creation du fichier policy
nano policy.hcl
path "kv/secret" {
capabilities = ["read"]
}
#creation de la policy
vault policy write titre-de-la-policy-readonly policy.hcl
#creation d`un token
nom-du-token
vault token create -policy="titre-de-la-policy-readonly"
Ressources
- Doc - hashicorp.com
- How To Securely Manage Secrets with HashiCorp Vault on Ubuntu 20.04 - digitalocean.com
Il existe d'autres solutions que je n'ai pas encore explorées:
Vault - Secret Manager