Skip to content

Vaultwarden experiment

I have been working in the engineering side of the organization to organize accounts we have with different online services. That work has identified that we have accounts that have been setup by different individuals over time (some who are no longer with us, many who should not even have access any longer), with different personal or outdated organization information configured, and their associated passwords being shared in numerous ways of various levels of security or insecurity (signal, matrix, email, etc.). Accounts such as google play store, apple developer console, dockerhub, domain fronting CDN providers, browser extension stores, AWS, GKE, etc. are strewn about in a fairly haphazard way. The goal of this effort is to bring sanity to these accounts and reduce the overhead involved in regaining access, performing necessary billing work, adjusting organizational details, updating legal agreements, etc. Having a single password vault for accounts that can be organized in ways that different people can have appropriate access would go a long ways towards making things less chaotic.

As we continue to evaluate passsword management options, and because there is a need in engineering to solve our messy password situation, I'd like to propose that we try an experiment with a vaultwarden server (the free software, rust rewrite of Bitwarden). I have been managing a valutwarden server for personal use, and it appears to work well, and functions well in organizations who have different access and client needs. My proposal is that TPA would setup and manage a VM, with the vaultwarden-server container setup, and I would manage the service. I would attempt to use this system to organize these efforts, and this can be simultaneously an opportunity to evaluate the relative merits of this system for potential wider use. We can check in on the effectiveness of this as we go along and change course without difficulty.

Vaultwarden was designed to run on a raspberry pi, and it appears that hosting up to 100 users works just fine on such a setup. Thus the required specifications for a server are quite minimal. Considering this is a experiment, I would suggest we start off with a minimal configuration and monitor it and adjust on the way.

Specs requested:

  • Memory: 512MB
  • CPU: 1 core
  • Storage: 5GB (in addition to what your typical Debian installation with podman would reuqire)
  • DNS: vault.torproject.org
  • Software: podman configured to auto-update the docker image vaultwarden/server:latest -- this tracks the latest released tagged version number with an appropriate rw volume/directory mounted on /data and port 80 exposed (-p 80:80), passing the following environment variables:
SIGNUPS_ALLOWED: false
ORG_CREATION_USERS: none
INVITATIONS_ALLOWED: false
INVITATION_ORG_NAME: Tor
DOMAIN: 'https://vault.torproject.org'
ADMIN_TOKEN: <provided out of band>
SMTP_HOST: <tpa provided>
SMTP_FROM: <tpa provided>
SMTP_USERNAME: <tpa provided>
SMTP_PASSWORD: <tpa provided>
SMTP_SECURITY: <tpa provided: starttls for 587, force_tls for 465)
SMTP_AUTH_MECHANISM: <tpa provided: Plain, Login, Xoauth2>
HELO_NAME: vault.torproject.org
TPA's choice:
USE_SYSLOG: true (depends on TPA logging policy)
LOG_FILE: /path/to/log (if not using syslog, depending on TPA log poligy)

  • Reverse Proxy: avec TLS certificate, please see these examples, presumably the normal nginx one there is what you would use, but if that isn't the typical tpa webserver, other options are there.

  • Backups: please backup the volume that is passed, it contains a sqlite database that is critical.

  • Firewall: ALL IN/OUT: port 443 for reverse proxy OUT: either port 587 or 465, depending on SMTP_SECURITY

Edited by micah