Quellen von Secrets in HashiCorp Vault - Neu aufgelegt

Gleiches Ziel, anderer Ansatz

Im vorherigen Artikel haben wir 1Password-Einträge per Terraform in Vault gespiegelt und dort im KV-Engine abgelegt. Dieses Muster passt, wenn Vault die kanonische Quelle für ein Secret werden soll. Manchmal reicht es jedoch, wenn Vault Secrets aus anderen Systemen zugänglich macht, damit bestehende Clients weiterhin denselben Workflow nutzen können.

Anstatt Daten zu kopieren, lassen wir Vault als Proxy agieren. Das 1Password Vault Plugin stellt einen eigenen Secrets-Engine-Endpunkt (op-connect) bereit, der CRUD-Operationen an die 1Password-Connect-API delegiert. Vault-User können lesen, auflisten, erstellen und rotieren, ohne jemals die Connect-Zugangsdaten zu sehen.

Architektur auf einen Blick

• Vault lädt das Plugin-Binary in den Plugin-Katalog und mountet es z.B. unter op/.
• Das Plugin spricht mit eurem selbst betriebenen 1Password-Connect-Server über ein Access-Token, das auf bestimmte Vaults/Items scoped ist.
• Vault-ACLs bestimmen, wer op/* aufrufen darf, sodass bestehendes RBAC und Audit-Logging weiterverwendet wird.
• Es entsteht kein zweiter Speicherort: 1Password bleibt Single Source of Truth, Vault liefert nur den gewohnten Zugriff.

Voraussetzungen

1. Ein laufender Vault-Server (OSS oder Enterprise) inklusive vault CLI.
2. Ein bereitgestellter 1Password-Connect-Server plus Access-Token für die freizugebenden Vaults.
3. Entweder ein heruntergeladenes Plugin-Binary oder eine lokale Go-Toolchain zum Selbstbau.

Lokal testen klappt mit einem Vault-Dev-Server:

1mkdir -p ./vault/plugins
2vault server -dev -dev-root-token-id=root -dev-plugin-dir=./vault/plugins -log-level=debug

⚠️ Der Dev-Mode bleibt unsealed und speichert nur im RAM. Bitte nicht für Produktion verwenden.

1Password Connect per Docker Compose betreiben

Falls noch kein Connect-Server läuft, hilft ein kompaktes Docker-Compose-Setup. Die API-Komponente nimmt Vault-Anfragen entgegen, der Sync-Service hält die Daten aktuell. Beide Container teilen sich Credentials und Daten-Volume, damit alles konsistent bleibt.

 1services:
 2	op-connect-api:
 3		image: 1password/connect-api:latest
 4		ports:
 5			- "127.0.0.1:8080:8080"
 6		volumes:
 7			- "/opt/opconnect/1password-credentials.json:/home/opuser/.op/1password-credentials.json"
 8			- "data:/home/opuser/.op/data"
 9	op-connect-sync:
10		image: 1password/connect-sync:latest
11		ports:
12			- "127.0.0.1:8081:8080"
13		volumes:
14			- "/opt/opconnect/1password-credentials.json:/home/opuser/.op/1password-credentials.json"
15			- "data:/home/opuser/.op/data"
16
17
18volumes:
19	data:

Die Datei 1password-credentials.json (aus dem Connect-Setup) gehört auf dem Host nach /opt/opconnect/ und sollte entsprechend geschützt werden. Nach docker compose up -d setzt ihr OP_CONNECT_HOST=http://127.0.0.1:8080 sowie OP_CONNECT_TOKEN auf das Access-Token aus 1Password. Vault kann daraufhin direkt mit dem lokalen Connect-API sprechen.

Plugin installieren

Ladet das passende Release für eure Vault-Architektur:

1# Beispiel für linux/amd64, Version/Dateiname ggf. anpassen
2unzip ./vault-plugin-secrets-onepassword_1.1.0_linux_amd64.zip
3mv ./vault-plugin-secrets-onepassword_v1.1.0 ./vault/plugins/op-connect

Lieber selbst bauen?

1# Binary direkt ins Plugin-Verzeichnis legen
2GOBIN=$(pwd)/vault/plugins go build -o ./vault/plugins/op-connect \
3	github.com/1Password/vault-plugin-secrets-onepassword

Anschließend Vault mit gesetztem Plugin-Verzeichnis starten. Minimalbeispiel:

1plugin_directory = "${PWD}/vault/plugins"
2api_addr         = "http://127.0.0.1:8200"
3
4storage "inmem" {}
5
6listener "tcp" {
7	address     = "127.0.0.1:8200"
8	tls_disable = "true"
9}

Secrets Engine registrieren und mounten

Sobald Vault läuft und entsiegelt ist, den SHA256-Hash berechnen und das Plugin registrieren (macOS-Beispiel):

1export VAULT_ADDR=http://127.0.0.1:8200
2SHA256_CHECKSUM=$(shasum -a 256 ./vault/plugins/op-connect | cut -d ' ' -f1)
3vault plugin register -sha256="$SHA256_CHECKSUM" -version=v1.1.0 secret op-connect

Danach die Engine mounten und die Connect-Daten hinterlegen:

1vault secrets enable --path=op op-connect
2vault write op/config \
3	op_connect_host=$OP_CONNECT_HOST \
4	op_connect_token=$OP_CONNECT_TOKEN

Wer die Werte nicht im Terminal anzeigen möchte, kann eine JSON-Datei verwenden:

1{
2	"op_connect_host": "https://op-connect.example.com:8443/",
3	"op_connect_token": "your_access_token"
4}

1vault write op/config @op-connect-config.json

In Vault-Enterprise-Namespaces müssen Enable- und Config-Befehle je Namespace ausgeführt werden (vault secrets enable -namespace=finance op).

Secrets aus 1Password via Vault konsumieren

Ab jetzt verhält sich op/ für Clients wie jede andere Engine:

1# Vaults finden, die das Token sehen darf
2vault list op/vaults
3
4# Items in einem bestimmten 1Password-Vault anzeigen
5vault list op/vaults/engineering/items
6
7# Einzelnes Item (Titel oder UUID) lesen
8vault read op/vaults/engineering/items/docker-hub-service-account

Erstellen oder Aktualisieren funktioniert mit JSON-Objekten im Connect-Schema:

1{
2	"category": "login",
3	"title": "Example Login",
4	"fields": [
5		{ "id": "username", "type": "STRING", "purpose": "USERNAME", "value": "my_user" },
6		{ "id": "password", "type": "CONCEALED", "purpose": "PASSWORD", "generate": true }
7	]
8}

1vault write op/vaults/engineering/items @login.json
2vault delete op/vaults/engineering/items/docker-hub-service-account

Im Hintergrund leitet das Plugin jede Anfrage an 1Password Connect weiter. Rotation, Audits und Berechtigungen bleiben also zentralisiert in 1Password.

Policy-Aspekte

Behandelt den Pfad op/* wie jede andere Engine, wenn ihr ACL-Policies schreibt. Ein einfaches Read-Only-Beispiel:

path "op/data" {
	capabilities = ["list"]
}

path "op/vaults/engineering/*" {
	capabilities = ["read", "list"]
}

Da Vault nur proxied, gilt Least Privilege doppelt:

1. Scope das 1Password-Connect-Token auf möglichst wenige Vaults.
2. Gebt nur den Rollen Zugriff, die op/* wirklich brauchen.
3. Haltet die Plugin-Binaries aktuell (Stand jetzt: v1.1.0).

Wann lohnt sich das Plugin-Muster?

• Ihr verwaltet operative Secrets bereits in 1Password, müsst sie aber für Vault-basierte Workloads freigeben.
• Ihr wollt keine Datenkopie in Vault pflegen, um Drift und separate Rotation zu vermeiden.
• Ihr braucht bidirektionale Aktionen (listen, read, create, update, delete) direkt über das Vault-CLI/API.

Wenn Vault stattdessen zum neuen System of Record werden soll, bleibt beim Synchronisations-Ansatz aus dem Ursprungsartikel. Für alle anderen Fälle bietet das 1Password-Secrets-Engine-Plugin den schnellsten Weg, beide Welten zusammenzubringen und Governance in 1Password zu belassen.

Meldet euch gern, wenn ihr Unterstützung bei Hardening, Terraform- oder Kubernetes-Integration braucht.