hashicorp/vaultUn outil de gestion des secrets, de chiffrement en tant que service et de gestion des accès privilégiés
Veuillez noter : Nous prenons la sécurité de Vault et la confiance de nos utilisateurs très au sérieux. Si vous pensez avoir trouvé un problème de sécurité dans Vault, veuillez le divulguer de manière responsable en nous contactant à l'adresse [email protected].
Vault est un outil pour accéder de manière sécurisée aux secrets. Un secret est tout ce dont vous souhaitez contrôler strictement l'accès, comme les clés API, mots de passe, certificats, etc. Vault fournit une interface unifiée pour tout secret, tout en offrant un contrôle d'accès strict et un journal d'audit détaillé.
Un système moderne nécessite l'accès à une multitude de secrets : identifiants de base de données, clés API pour des services externes, identifiants pour la communication d'architecture orientée services, etc. Comprendre qui accède à quels secrets est déjà très difficile et spécifique à chaque plateforme. Ajouter la rotation des clés, le stockage sécurisé et des journaux d'audit détaillés est presque impossible sans une solution personnalisée. C'est là que Vault intervient.
Les principales fonctionnalités de Vault sont :
Stockage sécurisé des secrets : Vault peut stocker des paires clé/valeur arbitraires. Vault chiffre les données avant de les écrire dans le stockage persistant, donc accéder au stockage brut ne suffit pas pour accéder à vos secrets. Vault peut écrire sur le disque, Consul, etc.
Secrets dynamiques : Vault peut générer des secrets à la demande pour certains systèmes, comme AWS ou les bases de données SQL. Par exemple, lorsqu'une application doit accéder à un bucket S3, elle demande des identifiants à Vault, et Vault génère une paire de clés AWS avec les permissions valides à la demande. Après avoir créé ces secrets dynamiques, Vault les révoque automatiquement une fois la durée de vie expirée.
Chiffrement des données : Vault peut chiffrer et déchiffrer des données sans les stocker. Cela permet aux équipes de sécurité de définir des paramètres de chiffrement et aux développeurs de stocker des données chiffrées dans un emplacement tel qu'une base de données SQL sans avoir à concevoir leurs propres méthodes de chiffrement.
Location et renouvellement : Vault associe chaque secret à une location (lease). À la fin de la location, Vault révoque automatiquement le secret. Les clients peuvent renouveler les locations via les API de renouvellement intégrées.
Révocation : Vault prend en charge la révocation des secrets. Vault peut révoquer non seulement un seul secret, mais aussi une arborescence de secrets, par exemple, tous les secrets lus par un utilisateur spécifique, ou tous les secrets d'un type particulier. La révocation facilite la rotation des clés ainsi que le verrouillage des systèmes en cas d'intrusion.
La documentation est disponible sur le site web de Vault.
Si vous débutez avec Vault et souhaitez commencer avec l'automatisation de la sécurité, veuillez consulter nos guides de démarrage sur la plateforme d'apprentissage de HashiCorp. Il existe également des guides supplémentaires pour poursuivre votre apprentissage.
Pour des exemples d'interaction avec Vault depuis votre application dans différents langages de programmation, consultez le dépôt vault-examples. Une application d'exemple prête à l'emploi est également disponible.
Montrez vos connaissances sur Vault en passant un examen de certification. Visitez la page de certification pour obtenir des informations sur les examens et trouvez des documents d'étude sur la plateforme d'apprentissage de HashiCorp.
Si vous souhaitez travailler sur Vault lui-même ou sur l'un de ses systèmes intégrés, vous aurez d'abord besoin d'installer Go sur votre machine.
Pour le développement local, assurez-vous d'abord que Go est correctement installé, y compris la configuration d'un GOPATH, puis définissez la variable GOBIN sur $GOPATH/bin. Assurez-vous que $GOPATH/bin est dans votre chemin car certaines distributions livrent l'ancienne version des outils de construction.
Ensuite, clonez ce dépôt. Vault utilise Go Modules, il est donc recommandé de cloner le dépôt en dehors du GOPATH. Vous pouvez ensuite télécharger les outils de construction nécessaires en initialisant votre environnement :
$ make bootstrap
...
Pour compiler une version de développement de Vault, exécutez make ou make dev. Cela mettra le binaire Vault dans les dossiers bin et $GOPATH/bin :
$ make dev
...
$ bin/vault
...
Pour compiler une version de développement de Vault avec l'interface utilisateur, exécutez make static-dist dev-ui. Cela mettra le binaire Vault dans les dossiers bin et $GOPATH/bin :
$ make static-dist dev-ui
...
$ bin/vault
...
Pour exécuter les tests, tapez make test. Remarque : cela nécessite que Docker soit installé. Si cela se termine avec un code de sortie 0, tout fonctionne !
$ make test
...
Si vous développez un package spécifique, vous pouvez exécuter les tests uniquement pour ce package en spécifiant la variable TEST. Par exemple ci-dessous, seuls les tests du package vault seront exécutés.
$ make test TEST=./vault
...
Si vous rencontrez une erreur comme could not read Username for 'https://github.com', vous devrez peut-être ajuster votre configuration git comme suit :
$ git config --global --add url."[email protected]:".insteadOf "https://github.com/"
Ce dépôt publie deux bibliothèques qui peuvent être importées par d'autres projets : github.com/hashicorp/vault/api et github.com/hashicorp/vault/sdk.
Notez que ce dépôt contient également Vault (le produit), et comme la plupart des projets Go, Vault utilise Go Modules pour gérer ses dépendances. Le mécanisme pour cela est le fichier go.mod. Il se trouve que la présence de ce fichier rend également théoriquement possible l'importation de Vault en tant que dépendance dans d'autres projets. Certains autres projets ont pris l'habitude de le faire afin de profiter des outils de test développés pour tester Vault lui-même. Ce n'est pas et n'a jamais été une façon prise en charge d'utiliser le projet Vault. Nous ne sommes pas susceptibles de corriger des bugs liés à l'échec de l'importation de github.com/hashicorp/vault dans votre projet.
Voir également la section « Tests basés sur Docker » ci-dessous.
Vault dispose de tests d'acceptation complets couvrant la plupart des fonctionnalités des méthodes secrètes et d'authentification.
Si vous travaillez sur une fonctionnalité d'une méthode secrète ou d'authentification et souhaitez vérifier qu'elle fonctionne (et qu'elle n'a rien cassé d'autre), nous vous recommandons d'exécuter les tests d'acceptation.
Avertissement : Les tests d'acceptation créent/détruisent/modifient des ressources réelles, ce qui peut entraîner des coûts réels dans certains cas. En présence d'un bug, il est techniquement possible que des backends défectueux laissent des données résiduelles. Par conséquent, veuillez exécuter les tests d'acceptation à vos propres risques. Au minimum, nous recommandons de les exécuter dans un compte privé dédié pour le backend que vous testez.
Pour exécuter les tests d'acceptation, invoquez make testacc :
$ make testacc TEST=./builtin/logical/consul
...
La variable TEST est obligatoire et vous devez spécifier le dossier où se trouve le backend. La variable TESTARGS est recommandée pour filtrer sur une ressource spécifique à tester, car tester toutes les ressources à la fois peut parfois prendre beaucoup de temps.
Les tests d'acceptation nécessitent généralement que d'autres variables d'environnement soient définies pour des éléments tels que les clés d'accès. Le test lui-même devrait échouer rapidement et vous indiquer quoi définir, ce n'est donc pas documenté ici.
Pour plus d'informations sur les fonctionnalités de Vault Enterprise, visitez le site Vault Enterprise.
Nous avons créé un nouveau mécanisme de test expérimental inspiré de NewTestCluster. Voici un exemple d'utilisation :
import (
"testing"
"github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)
func Test_Something_With_Docker(t *testing.T) {
opts := &docker.DockerClusterOptions{
ImageRepo: "hashicorp/vault", // or "hashicorp/vault-enterprise"
ImageTag: "latest",
}
cluster := docker.NewTestDockerCluster(t, opts)
client := cluster.Nodes()[0].APIClient()
_, err := client.Logical().Read("sys/storage/raft/configuration")
if err != nil {
t.Fatal(err)
}
}
Ou pour Enterprise :
import (
"testing"
"github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)
func Test_Something_With_Docker(t *testing.T) {
opts := &docker.DockerClusterOptions{
ImageRepo: "hashicorp/vault-enterprise",
ImageTag: "latest",
VaultLicense: licenseString, // not a path, the actual license bytes
}
cluster := docker.NewTestDockerCluster(t, opts)
}
Voici un exemple plus réaliste de la façon dont nous l'utilisons en pratique. DefaultOptions utilise hashicorp/vault:latest comme dépôt et tag, mais il examine également la variable d'environnement VAULT_BINARY. Si elle est renseignée, il copie le fichier local référencé par VAULT_BINARY dans le conteneur. Ceci est utile pour tester des modifications locales.
Au lieu de définir l'option VaultLicense, vous pouvez définir la variable d'environnement VAULT_LICENSE_CI, ce qui est préférable à la validation d'une licence dans le contrôle de version.
Vous pouvez éventuellement définir COMMIT_SHA, qui sera ajouté au nom de l'image que nous construisons comme aide au débogage.
func Test_Custom_Build_With_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
cluster := docker.NewTestDockerCluster(t, opts)
}
Il existe divers helpers dans le package github.com/hashicorp/vault/sdk/helper/testcluster, par exemple les tests ci-dessous créeront une paire de clusters à 3 nœuds et les relieront en utilisant respectivement la réplication PR ou DR, et échoueront si l'état de réplication ne devient pas sain avant l'expiration du contexte passé.
Encore une fois, tels qu'écrits, ils dépendent de la présence d'un binaire Vault Enterprise local et de la variable d'environnement VAULT_BINARY pointant vers celui-ci, ainsi que de VAULT_LICENSE_CI définie.
func TestStandardPerfReplication_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
r, err := docker.NewReplicationSetDocker(t, opts)
if err != nil {
t.Fatal(err)
}
defer r.Cleanup()
ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
defer cancel()
err = r.StandardPerfReplication(ctx)
if err != nil {
t.Fatal(err)
}
}
func TestStandardDRReplication_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
r, err := docker.NewReplicationSetDocker(t, opts)
if err != nil {
t.Fatal(err)
}
defer r.Cleanup()
ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
defer cancel()
err = r.StandardDRReplication(ctx)
if err != nil {
t.Fatal(err)
}
}
Enfin, voici un exemple d'exécution d'un test Docker OSS existant avec un binaire personnalisé :
$ GOOS=linux make dev
$ VAULT_BINARY=$(pwd)/bin/vault go test -run 'TestRaft_Configuration_Docker' ./vault/external_tests/raft/raft_binary
ok github.com/hashicorp/vault/vault/external_tests/raft/raft_binary 20.960s