hashicorp/vaultEin Werkzeug für die Verwaltung von Geheimnissen, Verschlüsselung als Dienstleistung und privilegiertes Zugriffsmanagement
Bitte beachten: Wir nehmen die Sicherheit von Vault und das Vertrauen unserer Benutzer sehr ernst. Wenn Sie glauben, ein Sicherheitsproblem in Vault gefunden zu haben, teilen Sie es uns bitte verantwortungsvoll mit, indem Sie uns unter [email protected] kontaktieren.
Vault ist ein Werkzeug für den sicheren Zugriff auf Geheimnisse. Ein Geheimnis ist alles, auf das Sie den Zugriff streng kontrollieren möchten, wie API-Schlüssel, Passwörter, Zertifikate und mehr. Vault bietet eine einheitliche Schnittstelle für jedes Geheimnis, mit strenger Zugriffskontrolle und detaillierten Prüfprotokollen.
Ein modernes System benötigt Zugriff auf eine Vielzahl von Geheimnissen: Datenbank-Anmeldedaten, API-Schlüssel für externe Dienste, Anmeldedaten für die Kommunikation in serviceorientierten Architekturen usw. Zu verstehen, wer auf welche Geheimnisse zugreift, ist bereits sehr schwierig und plattformspezifisch. Hinzu kommen Schlüsselrotation, sichere Speicherung und detaillierte Prüfprotokolle – das ist ohne eine benutzerdefinierte Lösung nahezu unmöglich. Hier kommt Vault ins Spiel.
Die Hauptfunktionen von Vault sind:
Sichere Geheimnisspeicherung: Vault kann beliebige Schlüssel/Wert-Paare speichern. Vault verschlüsselt Daten, bevor sie in den persistenten Speicher geschrieben werden, sodass der Zugriff auf den Rohspeicher nicht ausreicht, um Ihre Geheimnisse zu erhalten. Vault kann auf die Festplatte, Consul und mehr schreiben.
Dynamische Geheimnisse: Vault kann bei Bedarf Geheimnisse für einige Systeme generieren, z. B. für AWS oder SQL-Datenbanken. Wenn eine Anwendung beispielsweise auf einen S3-Bucket zugreifen muss, fragt sie Vault nach Anmeldedaten, und Vault generiert ein AWS-Schlüsselpaar mit gültigen Berechtigungen. Nach der Erstellung dieser dynamischen Geheimnisse widerruft Vault sie automatisch, sobald die Lease abläuft.
Datenverschlüsselung: Vault kann Daten verschlüsseln und entschlüsseln, ohne sie zu speichern. Dadurch können Sicherheitsteams Verschlüsselungsparameter definieren und Entwickler verschlüsselte Daten an einem Ort wie einer SQL-Datenbank speichern, ohne eigene Verschlüsselungsmethoden entwerfen zu müssen.
Leasing und Verlängerung: Vault ordnet jedem Geheimnis eine Lease zu. Am Ende der Lease widerruft Vault das Geheimnis automatisch. Clients können Leases über integrierte Verlängerungs-APIs verlängern.
Widerruf: Vault bietet integrierte Unterstützung für den Widerruf von Geheimnissen. Vault kann nicht nur einzelne Geheimnisse widerrufen, sondern auch einen Baum von Geheimnissen, z. B. alle von einem bestimmten Benutzer gelesenen Geheimnisse oder alle Geheimnisse eines bestimmten Typs. Der Widerruf unterstützt sowohl die Schlüsselrotation als auch das Sperren von Systemen im Falle eines Einbruchs.
Die Dokumentation ist auf der Vault-Website verfügbar.
Wenn Sie neu bei Vault sind und mit der Sicherheitsautomation beginnen möchten, lesen Sie bitte unsere Anleitungen für den Einstieg auf der Lernplattform von HashiCorp. Es gibt auch weitere Anleitungen, um Ihr Lernen fortzusetzen.
Beispiele für die Interaktion mit Vault aus Ihrer Anwendung in verschiedenen Programmiersprachen finden Sie im Repository vault-examples. Eine sofort einsatzbereite Beispielanwendung ist ebenfalls verfügbar.
Zeigen Sie Ihr Vault-Wissen, indem Sie eine Zertifizierungsprüfung bestehen. Besuchen Sie die Zertifizierungsseite für Informationen zu Prüfungen und finden Sie Lernmaterialien auf der Lernplattform von HashiCorp.
Wenn Sie an Vault selbst oder an einem seiner integrierten Systeme arbeiten möchten, müssen Sie zunächst Go auf Ihrem Rechner installieren.
Stellen Sie für die lokale Entwicklung zunächst sicher, dass Go ordnungsgemäß installiert ist, einschließlich der Einrichtung eines GOPATH. Setzen Sie dann die Variable GOBIN auf $GOPATH/bin. Achten Sie darauf, dass $GOPATH/bin in Ihrem Pfad enthalten ist, da einige Distributionen die alte Version der Build-Tools bündeln.
Klonen Sie als nächstes dieses Repository. Vault verwendet Go Modules, daher wird empfohlen, das Repository außerhalb des GOPATH zu klonen. Sie können dann alle erforderlichen Build-Tools durch Bootstrap Ihrer Umgebung herunterladen:
$ make bootstrap
...
Um eine Entwicklungsversion von Vault zu kompilieren, führen Sie make oder make dev aus. Dadurch wird die Vault-Binärdatei in den bin- und $GOPATH/bin-Ordnern abgelegt:
$ make dev
...
$ bin/vault
...
Um eine Entwicklungsversion von Vault mit der Benutzeroberfläche zu kompilieren, führen Sie make static-dist dev-ui aus. Dadurch wird die Vault-Binärdatei in den bin- und $GOPATH/bin-Ordnern abgelegt:
$ make static-dist dev-ui
...
$ bin/vault
...
Um Tests auszuführen, geben Sie make test ein. Hinweis: Dazu muss Docker installiert sein. Wenn der Befehl mit Exit-Status 0 beendet wird, funktioniert alles!
$ make test
...
Wenn Sie an einem bestimmten Paket entwickeln, können Sie Tests nur für dieses Paket ausführen, indem Sie die Variable TEST angeben. Im folgenden Beispiel werden nur Tests des Pakets vault ausgeführt.
$ make test TEST=./vault
...
Wenn ein Fehler wie could not read Username for 'https://github.com' auftritt, müssen Sie möglicherweise Ihre Git-Konfiguration wie folgt anpassen:
$ git config --global --add url."[email protected]:".insteadOf "https://github.com/"
Dieses Repository veröffentlicht zwei Bibliotheken, die von anderen Projekten importiert werden können: github.com/hashicorp/vault/api und github.com/hashicorp/vault/sdk.
Beachten Sie, dass dieses Repository auch Vault (das Produkt) enthält, und wie bei den meisten Go-Projekten verwendet Vault Go Modules zur Verwaltung seiner Abhängigkeiten. Der Mechanismus dafür ist die Datei go.mod. Es kommt vor, dass das Vorhandensein dieser Datei es theoretisch ermöglicht, Vault als Abhängigkeit in andere Projekte zu importieren. Einige andere Projekte haben dies praktiziert, um von Testwerkzeugen zu profitieren, die für das Testen von Vault selbst entwickelt wurden. Dies ist keine unterstützte Art der Verwendung des Vault-Projekts und war es auch nie. Es ist unwahrscheinlich, dass wir Fehler beheben, die mit dem Fehlschlagen des Imports von github.com/hashicorp/vault in Ihr Projekt zusammenhängen.
Siehe auch den Abschnitt „Docker-basierte Tests“ weiter unten.
Vault verfügt über umfassende Akzeptanztests, die die meisten Funktionen der Secret- und Auth-Methoden abdecken.
Wenn Sie an einer Funktion einer Secret- oder Auth-Methode arbeiten und überprüfen möchten, ob sie funktioniert (und auch nichts anderes beschädigt hat), empfehlen wir die Ausführung der Akzeptanztests.
Warnung: Die Akzeptanztests erstellen/zerstören/modifizieren echte Ressourcen, was in einigen Fällen zu echten Kosten führen kann. Bei einem Fehler ist es technisch möglich, dass defekte Backends verwaiste Daten hinterlassen. Daher führen Sie die Akzeptanztests bitte auf eigenes Risiko aus. Wir empfehlen zumindest, sie in einem eigenen privaten Konto für das von Ihnen getestete Backend auszuführen.
Um die Akzeptanztests auszuführen, rufen Sie make testacc auf:
$ make testacc TEST=./builtin/logical/consul
...
Die Variable TEST ist erforderlich und Sie sollten den Ordner angeben, in dem sich das Backend befindet. Die Variable TESTARGS wird empfohlen, um auf eine bestimmte zu testende Ressource zu filtern, da das gleichzeitige Testen aller oft sehr lange dauern kann.
Akzeptanztests erfordern normalerweise das Setzen weiterer Umgebungsvariablen für Dinge wie Zugriffsschlüssel. Der Test sollte selbst frühzeitig einen Fehler ausgeben und Ihnen mitteilen, was Sie setzen müssen, daher wird es hier nicht dokumentiert.
Weitere Informationen zu den Funktionen von Vault Enterprise finden Sie auf der Vault Enterprise-Website.
Wir haben einen experimentellen neuen Testmechanismus entwickelt, der von NewTestCluster inspiriert ist. Ein Beispiel für seine Verwendung:
import (
"testing"
"github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)
func Test_Something_With_Docker(t *testing.T) {
opts := &docker.DockerClusterOptions{
ImageRepo: "hashicorp/vault", // oder "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)
}
}
Oder für 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, // kein Pfad, die tatsächlichen Lizenz-Bytes
}
cluster := docker.NewTestDockerCluster(t, opts)
}
Hier ist ein realistischeres Beispiel dafür, wie wir es in der Praxis verwenden. DefaultOptions verwendet hashicorp/vault:latest als Repo und Tag, prüft aber auch die Umgebungsvariable VAULT_BINARY. Wenn diese gesetzt ist, wird die lokale Datei, auf die VAULT_BINARY verweist, in den Container kopiert. Dies ist nützlich, wenn Sie lokale Änderungen testen.
Anstatt die Option VaultLicense zu setzen, können Sie die Umgebungsvariable VAULT_LICENSE_CI setzen, was besser ist, als eine Lizenz in die Versionskontrolle zu übernehmen.
Optional können Sie COMMIT_SHA setzen, das dem von uns erstellten Image-Namen als Debugging-Hilfe angehängt wird.
func Test_Custom_Build_With_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
cluster := docker.NewTestDockerCluster(t, opts)
}
Es gibt eine Vielzahl von Hilfsfunktionen im Paket github.com/hashicorp/vault/sdk/helper/testcluster, z. B. erstellen die folgenden Tests ein Paar von 3-Knoten-Clustern und verknüpfen sie mithilfe von PR- bzw. DR-Replikation, und schlagen fehl, wenn der Replikationsstatus nicht gesund wird, bevor der übergebene Kontext abläuft.
Auch diese hängen, wie beschrieben, davon ab, dass eine Vault Enterprise-Binärdatei lokal vorhanden ist und die Umgebungsvariable VAULT_BINARY auf diese verweist, sowie dass VAULT_LICENSE_CI gesetzt ist.
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)
}
}
Schließlich ein Beispiel für die Ausführung eines vorhandenen OSS-Docker-Tests mit einer benutzerdefinierten Binärdatei:
$ 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