Vault auf Debian: Secrets einsperren, bevor sie im Git landen

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:

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:

# /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:

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.

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:

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:

# ansible-prod.hcl
path "kv/data/prod/*" {
  capabilities = ["read"]
}
path "kv/metadata/prod/*" {
  capabilities = ["list"]
}

Policy laden:

vault policy write ansible-prod ansible-prod.hcl

Für Skripte kannst du Tokens erzeugen, aber bitte mit TTL und Policy:

vault token create -policy=ansible-prod -ttl=1h

In Bash sieht der Zugriff dann angenehm unspektakulär aus:

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:

ansible-galaxy collection install community.hashi_vault

Beispiel im Playbook:

- 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.