Passwörter in `group_vars/all.yml`, API-Keys in Bash-Skripten und das Datenbank-Passwort in der Doku: Das ist kein Secret-Management, das ist digitale Zettelwirtschaft mit Ansage. Also haben wir HashiCorp Vault auf Debian geworfen und geguckt, wie schnell man damit von „liegt irgendwo rum“ zu „zentral, versionierbar und kontrolliert“ kommt.
Wir starten auf einem frischen Debian-System. Erst das HashiCorp-Repo einbinden:
```bash
sudo apt update
sudo apt install -y gpg curl lsb-release
curl -fsSL https://apt.releases.hashicorp.com/gpg | \
sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [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
sudo apt update
sudo apt install -y vault
```
Für einen echten Betrieb bitte nicht den Dev-Mode nehmen. Der ist praktisch, aber ungefähr so sicher wie ein Root-Login per Zuruf. Eine minimale Config sieht so aus:
```hcl
/etc/vault.d/vault.hcl
storage "file" {
path = "/opt/vault/data"
}
listener "tcp" {
address = "0.0.0.0:8200"
tls_disable = 0
tls_cert_file = "/etc/vault.d/tls/vault.crt"
tls_key_file = "/etc/vault.d/tls/vault.key"
}
api_addr = "https://vault.example.net:8200"
ui = true
```
Dann Rechte setzen und starten:
```bash
sudo mkdir -p /opt/vault/data /etc/vault.d/tls
sudo chown -R vault:vault /opt/vault/data /etc/vault.d
sudo systemctl enable --now vault
```
Jetzt wird Vault initialisiert. Dabei bekommst du Unseal Keys und ein Root Token. Die gehören nicht in Slack, nicht ins Wiki, nicht in `notes.txt`. Am besten sauber splitten und sicher ablegen.
```bash
export VAULT_ADDR=https://vault.example.net:8200
vault operator init
vault operator unseal
vault login
```
Für klassische Key-Value-Secrets aktivieren wir KV v2:
```bash
vault secrets enable -path=kv kv-v2
vault kv put kv/prod/database username="app" password="SuperGeheim123"
vault kv get kv/prod/database
```
Jetzt kommt der Teil, der Vault nützlich macht: Policies. Nicht jeder Client braucht alles. Ein Ansible-Runner soll zum Beispiel nur Produktionsdaten lesen:
```hcl
ansible-prod.hcl
path "kv/data/prod/*" {
capabilities = ["read"]
}
path "kv/metadata/prod/*" {
capabilities = ["list"]
}
```
Policy laden:
```bash
vault policy write ansible-prod ansible-prod.hcl
```
Für Skripte kannst du Tokens erzeugen, aber bitte mit TTL und Policy:
```bash
vault token create -policy=ansible-prod -ttl=1h
```
In Bash sieht der Zugriff dann angenehm unspektakulär aus:
```bash
export VAULT_ADDR=https://vault.example.net:8200
export VAULT_TOKEN="s.xxxxx"
DB_PASS=$(vault kv get -field=password kv/prod/database)
echo "Passwort geholt, aber nicht geloggt. Wir sind ja keine Barbaren."
```
Für Ansible gibt es die Collection:
```bash
ansible-galaxy collection install community.hashi_vault
```
Beispiel im Playbook:
```yaml
- name: Secret aus Vault lesen
hosts: appserver
vars:
db_password: "{{ lookup('community.hashi_vault.hashi_vault',
'secret=kv/data/prod/database:password',
url='https://vault.example.net:8200',
token=lookup('env', 'VAULT_TOKEN')) }}"
tasks:
- name: Config schreiben
template:
src: app.conf.j2
dest: /etc/app/app.conf
mode: '0600'
```
Wichtig: Token nicht hart ins Playbook tackern. Lieber per CI-Variable, Environment oder noch besser über AppRole, Kubernetes Auth oder LDAP/OIDC arbeiten. Für den Einstieg reicht ein kurzlebiges Token, für Produktion sollte die Authentifizierung sauber modelliert sein.
Unser Fazit nach dem Schrauben: Vault ist kein magischer Geheimnisstaubsauger. Du musst Policies, Auth-Methoden, TLS, Backups und Unseal-Prozess ordentlich bauen. Aber sobald das steht, verschwinden Secrets aus Git, Skripten und Bauchgefühl. Und das ist ein ziemlich guter Deal.