VaultwardenをHTTPS前提のコンテナで運用する

Bitwarden Client APIの実装範囲

VaultwardenはRustで書かれたBitwarden Client APIの代替サーバー実装で、公式Bitwardenクライアントとの互換性をREADMEが説明しています。公式サービスよりリソースを使わない自己ホスト環境が用途です。「nearly complete implementation」はREADMEの自己説明であり、利用する全機能が各クライアントで同じと証明するものではありません。

Personal Vault、Send、Attachments、Website icons、Personal API Key、Organizationsを提供するとされています。OrganizationsにはCollections、Password Sharing、Member Roles、Groups、Event Logs、Admin Password Reset、Directory Connector、Policiesが含まれます。採用前に必要機能を一覧と照合します。

コンテナを再作成しても/dataのデータが残ることを確認し、DOMAINのURLへHTTPSでアクセスできる状態を保ちます。

二要素認証と管理画面

Multi/Two Factor AuthenticationとしてAuthenticator、Email、FIDO2 WebAuthn、YubiKey、Duoが挙げられています。Emergency Access、Vaultwarden Admin Backend、コンテナに同梱されるModified Web Vault clientもREADMEに記載されています。機能名があることと組織の復旧手順に合うことは別なので、テストアカウントで確認します。

Admin Backendの有効化やWeb Vaultの詳細はWikiへ分かれています。トップREADMEだけで管理画面の公開方法や設定値を決めず、使用する版に対応するWikiを読みます。

HTTPSが有効でも、Bitwardenクライアントの同期や添付ファイルの復元結果は別に点検します。

Web Vaultに必要なHTTPS

Web VaultはHTTPSとsecure contextを要求し、Web Crypto APIの条件によりHTTPSを有効にしなければ動かないとREADMEは明記しています。127.0.0.1:8000へ公開するDocker例は、外部利用のHTTPS終端を構成した例ではありません。HTTPだけで本番利用できると考えないでください。

RocketにはTLSサポートがありますが、READMEの推奨はreverse proxyです。Proxy examplesのWikiを参照し、DOMAINの https://vw.domain.tld、証明書、転送先を対応させます。証明書更新と公開範囲はコンテナ起動とは別に確認します。

VaultwardenのDOMAIN、永続領域、証明書、クライアント機能を一つずつ確認します。

DockerとPodmanの永続化

推奨導入はコンテナイメージで、ghcr.io、docker.ioのvaultwarden/server、quay.ioが配布先です。CLI例は docker pull vaultwarden/server:latest、/vw-data/:/data/のマウント、127.0.0.1:8000:80の公開です。podmanを使う場合はdockerを置き換えられます。

Composeでは vaultwarden/server:latest、DOMAIN、./vw-data/:/data/、127.0.0.1:8000:80を設定します。/vw-dataに永続データを置く構成なので、更新前にバックアップと復元を確認します。latestを無条件に適用せず、採用したイメージ版を記録してください。

Bitwarden公式クライアントを接続する前に、Vaultwardenのコンテナログ、HTTPS証明書、reverse proxyの転送先を確認します。/dataのバックアップと復元をテストし、管理画面やWeb Vaultを必要な範囲だけ公開します。READMEの対応機能を確認しても、組織の権限設計や保管庫の復旧が完了するわけではないため、テストアカウントで同期結果を確認します。

イメージの選択と更新

コンテナのタグ選択はWhich container image to useのWikiで説明されています。第三者パッケージもありますが、最新版より遅れたり、Vaultwardenの設定方法から外れたりする場合があります。コンテナ、第三者パッケージ、自前ビルドを同じ導入手順として扱わず、取得元とデータパスを固定します。

自前ビルドはBuilding binaryのWikiへ案内されています。障害時は最新Vaultwardenを使っているか、既存issueとDiscussionsに同じ報告がないかを確認します。更新後はログイン、同期、添付、二要素認証、バックアップ復元を必要な範囲で再確認します。

Vaultwardenの運用記録には、使用イメージの配布先、タグ、DOMAIN、コンテナの/dataマウント、reverse proxyの設定を残します。docker runの127.0.0.1:8000:80は外部公開を意味しないため、HTTPS終端とアクセス範囲を別に確認します。Web Vaultのsecure context、Web Crypto API、証明書の更新を確認してからBitwardenクライアントを接続します。第三者パッケージは最新版から遅れる可能性があるため、Wikiの説明と実際の設定を比較します。更新前後にテスト保管庫の同期と復元を試します。

Vaultwardenの導入では、Web VaultのHTTPS、reverse proxyの転送、DOMAINの値、/dataの永続化を確認します。テスト用保管庫でログインと同期を行い、必要なBitwarden機能の結果を保存してから本番データを移行します。

自己ホストの具体的な条件

質問や提案の窓口はMatrix、GitHub Discussions、Discourseです。公式BitwardenのサポートチャンネルではなくVaultwardenへバグや提案を報告するようREADMEが注意しています。

最初はテスト用アカウントで必要なBitwarden機能だけを試し、DOMAIN、HTTPS証明書、reverse proxyの転送、/dataの永続化を確認します。Web VaultがHTTPSで開けない、復元したデータが読めない、公開範囲を制御できない場合は、本番の保管庫を移行しません。

DOMAINに設定したURLとreverse proxyのホスト名、証明書の対象名を一致させ、Web Crypto APIが使えるHTTPSのsecure contextを確認します。/dataへマウントしたディレクトリを更新前にバックアップし、Docker CLIとComposeで同じ保存先を使います。Bitwardenクライアントの同期、Send、添付、組織、FIDO2のうち必要な機能を一つずつ試し、公式サポート窓口へ誤送信しないようVaultwardenの報告先を使います。

VaultwardenではDOMAINのHTTPS URL、reverse proxy、Web Vaultのsecure contextを先に構成します。docker runの/vw-data/:/data/とComposeの./vw-data/:/data/が同じ永続領域を指すかを確認し、更新前のバックアップから復元できるかを試します。ghcr.io、docker.io、quay.ioのどれから取得したかを記録し、第三者パッケージの遅れや設定差をWikiで確認します。必要なSend、Attachments、Organizations、FIDO2をテスト用アカウントで検証します。

編集部の結論

Bitwarden互換クライアントを自分の環境で運用したい人には、Vaultwardenのコンテナイメージと永続ボリュームの構成が分かりやすい候補です。公式サービスとの完全同一性や、HTTPSなしの運用を求める環境には向きません。最初に対応したいBitwarden機能を確認し、DOMAIN、/data、localhost:8000、HTTPS、reverse proxyを検証環境で確かめてください。

公式情報源

1. Official README
2. Project repository
3. Release notes