Vaultwarden

Vaultwarden ist ein selbst gehosteter, Bitwarden-kompatibler Passwortmanager. iac-vaultwarden baut den Rust-Server im Debian-13-Gast aus einem verifizierten Upstream-Tag und installiert die dazu passende Web-Vault-Version.

Teil von iac.

Installation

Auf der Proxmox-Node:

bash -c "$(curl -fsSL https://iac.heyer.systems/vaultwarden/ct.sh)"   # LXC
bash -c "$(curl -fsSL https://iac.heyer.systems/vaultwarden/vm.sh)"   # VM

Beim Anlegen kann var_vaultwarden_domain auf die vollständige öffentliche HTTPS-Adresse gesetzt werden, z. B. https://vault.example.org.

Zugriff und TLS

Vaultwarden lauscht auf TCP 8080 und ist in der iac-Firewall nur aus privaten Netzen erreichbar. Der Dienst stellt selbst kein TLS bereit. Betreibe ihn hinter einem HTTPS-Reverse-Proxy, z. B. Traefik, und leite Anfragen intern an http://<IP>:8080 weiter. Die Web-Vault benötigt HTTPS beziehungsweise einen sicheren Browser-Kontext.

Die Registrierung ist standardmäßig deaktiviert. So kann nach dem Start nicht beliebig jeder ein Konto erstellen. Um das erste Konto anzulegen:

1. Stelle sicher, dass der Reverse-Proxy mit gültigem HTTPS-Zertifikat erreichbar ist.

2. Lege im Gast eine lokale, nicht von iac verwaltete Override-Datei an:

   install -o root -g root -m 0600 /dev/null /etc/vaultwarden/vaultwarden.local.env
   printf 'SIGNUPS_ALLOWED=true\n' >> /etc/vaultwarden/vaultwarden.local.env
   systemctl restart vaultwarden
   

3. Registriere das erste Konto über die HTTPS-Adresse.

4. Deaktiviere die Registrierung sofort wieder und starte den Dienst neu:

   sed -i '/^SIGNUPS_ALLOWED=/d' /etc/vaultwarden/vaultwarden.local.env
   systemctl restart vaultwarden
   

   Die verwaltete Konfiguration setzt SIGNUPS_ALLOWED=false; die lokale Override-Datei sollte danach keine entsprechende Zeile mehr enthalten.

Die Admin-Seite ist unter /admin erreichbar. Das Admin-Token liegt nur als Geheimnis in /etc/iac/settings.env; im Gast anzeigen:

grep vaultwarden_admin_token /etc/iac/settings.env

Das Token wird vor dem Schreiben in die Vaultwarden-Konfiguration als Argon2id-PHC-Hash gespeichert. Der Rohwert steht nicht in der systemd-Unit oder der verwalteten Vaultwarden-Konfiguration. Für eine Rotation den Wert in /etc/iac/settings.env ändern, /etc/vaultwarden/admin_token.hash entfernen und update ausführen.

Daten und Konfiguration

Pfad	Zweck
/var/lib/vaultwarden/	SQLite-Datenbank, Anhänge, Schlüssel und sonstige Laufzeitdaten; persistent
/etc/vaultwarden/vaultwarden.env	von iac verwaltete Konfiguration, einschließlich Admin-Token-Hash
/etc/vaultwarden/vaultwarden.local.env	optionale lokale Overrides; wird von iac nicht überschrieben
/opt/vaultwarden/	Symlink auf die aktive versionierte Installation
/opt/vaultwarden-<version>/	Server-Binary und passende Web-Vault-Dateien je Version; vorherige Versionen bleiben für Rollback erhalten

Die Datenbank ist standardmäßig SQLite. Es wird kein externer Datenbankdienst benötigt. Sichere /var/lib/vaultwarden regelmäßig und teste die Wiederherstellung; dort liegen die Passwortdaten und Anhänge.

Herkunft und Integrität

• Der Server wird aus https://github.com/dani-garcia/vaultwarden gebaut. Der Build prüft die GPG-Signatur des Release-Tags gegen fest hinterlegte Fingerprints der bekannten Upstream-Maintainer: Daniel García B9B7A108373276BF3C0406F9FC8A7D14C3CD543A und BlackDex 3C5BBC173D81186CFFDE72A958C80A2AA6C765E1. Die öffentlichen Schlüssel werden über HTTPS von den Upstream-Profilen geladen; ihre Fingerprints sind im Projekt fest gepinnt. Eine Schlüsselrotation muss deshalb bewusst geprüft und im Projekt angepasst werden. Der im Tag enthaltene Cargo.lock pinnt Rust-Abhängigkeiten und deren Prüfsummen.
• Die passende Web-Vault-Version wird aus dem Dockerfile des signierten Vaultwarden-Tags ermittelt. Das Archiv stammt aus dani-garcia/bw_web_builds; get_url prüft dessen veröffentlichte SHA-256-Prüfsumme, danach prüft GPG die abgetrennte Signatur des Archivs gegen den Vaultwarden-Security-Schlüssel 13BB3A34C9E380258CE43D595CB150B31F6426BC (veröffentlicht in SECURITY.md des Vaultwarden-Repos, geladen von keys.openpgp.org). Vor dem Entpacken muss außerdem die erwartete Dateistruktur vorhanden sein.
• Die Web-Vault wird als von Upstream gebautes Release-Archiv installiert, nicht auf dem Zielsystem mit Node.js neu kompiliert. Ihre Build-Quellen und Patches liegen in den Upstream-Repositories dani-garcia/bw_web_builds und vaultwarden/vw_web_builds.
• Vertrauensannahmen: HTTPS/TLS zu GitHub, die gepflegten GPG-Schlüssel der Upstream-Maintainer, die offizielle Rust-Toolchain-Distribution sowie die Prüfsummen der in Cargo.lock festgelegten Rust-Abhängigkeiten. Unbekannte oder ungültig signierte Tags und Web-Vault-Archive werden abgelehnt.

Update

Im Gast:

update

Die Rust-Toolchain und Build-Abhängigkeiten bleiben installiert, damit Updates im Gast erneut aus dem Quellcode bauen können. Bei einem Update wird der neue Server gebaut, die passende Web-Vault geprüft und gemeinsam mit dem Binary als versionierter Stand aktiviert. Danach wird /alive geprüft. Schlägt die Prüfung fehl, zeigt der aktive Symlink wieder auf die vorherige Version und der Dienst wird zurückgestartet.

Selbsttest

bash /var/lib/iac/src/core/bin/iac-smoke