スマートフォンから利用可能な、パスワード管理サーバのBitwarden。
その互換サーバのVaultwardenを、自宅のおうちKubernetesにデプロイしまして。
外出先から使用できるように、IPv4 PPPoE接続したRaspberry PiにてSSLでホスティングしてみました。
SSL化に使用したCaddyはLet’s Encrypt/ZeroSSLの証明書の自動更新に対応しているため、なにか契約や維持費は必要なく、なにか操作する必要もなく、ずっと使える予定です。
とはいえ、ダイナミックDNSのNo-IPが無料プランの場合、30日おきに手動の認証は必要ですが。
構築手順を記録させて頂こうと思います。
VaultwardenのKubernetesデプロイとSSLホスティング設定例
使用する機材
マシンはRaspberry Pi 4を複数台使用
[amazonjs asin=”B0891RC99L” locale=”JP” title=”Raspberrypi 正規代理店商品 Raspberry Pi 4 Model B (8GB) made in UK element14製 技適マーク入”]Kubernetesのノードとして、Raspberry Pi 4を3台使用しています。OSはFedora CoreOSになります。
Kubernetesとは別に、インターネットにサーバをホスティングするために、Raspberry Pi 4を1台使用しています。こちらのOSは、RHEL9互換のRocky Linux 9を使用させて頂いております。
データはSSDの分散ストレージ保存
[amazonjs asin=”B08N4JHGJL” locale=”JP” title=”【Amazon.co.jp限定】バッファロー SSD 外付け 1.0TB 超小型 コンパクト ポータブル PS5/PS4対応(メーカー動作確認済) USB3.2Gen1 ブラック SSD-PUT1.0U3-B/N”]Kubernetesのノードは、USBスティックSSDから起動しています。
Fedora CoreOSに64GB使用しました。残りの容量は、Rook Cephによる分散ストレージとして使用しています。KubernetesのPV(永続ボリューム)として、デプロイしたサービスのデータの保存先として使用しています。
Kubernetesの構築
ノード用にRaspberry Pi 4が3台、Kubernetesの管理用・インターネット接続プロキシ用に、Raspberry Pi 3を1台使用しました。
Kubernetesのデプロイ
Kubernetesの構築は、こちらの記事になります。各ノードにFedora CoreOSをプロビジョニング後、Kubesprayによる自動構築を行いました。
アーキテクチャはaarch64になりますが、今回問題なく、Vaultwardenが動作しました。
ロードバランサのデプロイ
KubesprayにてロードバランサMetalLBをデプロイしました。
Kubernetesにデプロイするサービスに、IPアドレスが付与されます。EXTERNAL-IP欄ですが、自宅LANのセグメントになります。
今回、Vaultwardenに192.168.xxx.63のIPアドレスが割り当てられました。CaddyのリバースプロキシのIPアドレスに、こちらを指定する流れになります。
KubernetesへVaultwardenをデプロイ
Helmのインストール
それでは、実際におうちKubernetesへVaultwardenをデプロイしたいと思います。
デプロイはHelmを使用させて頂きました。
Fedora CoreOSの場合、KubesprayではHelmをデプロイできなかったため、こちらの記事の手順で手動でインストールしました。
Vaultwardenのデプロイ
今回はこちらのチャートを使用させて頂きました。
[blogcard url=”https://artifacthub.io/packages/helm/gissilabs/vaultwarden”]
Helmのリポジトリを追加します。
helm repo add gissilabs https://gissilabs.github.io/charts/続いてhelm installコマンドでVaultwardenをデプロイしました。
次のパラメータを指定しました。
- データベースは既定のsqliteを使用
- service.typeとしてLoadBalancerを指定
- PV(永続ボリューム)を有効化
- Vaultwardenからメールを送信できるように、SMTPサーバ・メールアドレス・ユーザ名・パスワードを設定
よりセキュリティを強化するために、ネームスペースを指定して、他のポッドからアクセスできなくしたほうが良いと思います。(忘れてた
# namespaceは事前に作成
kubectl create namespace vw
helm install myvaultwarden gissilabs/vaultwarden \
--set service.type=LoadBalancer \
--set persistence.enabled=true \
--set vaultwarden.smtp.host=<smtpサーバ名> \
--set vaultwarden.smtp.from=<smtpメール送信元アドレス> \
--set vaultwarden.smtp.user=<smtpユーザ名> \
--set vaultwarden.smtp.password=<smtpパスワード> \
--namespace vwデータベースにsqliteを使用する場合、永続化ボリューム(PV)を使用しないとポッド削除とともにデータが消えてしまいます。このためPVを有効にしました。
smtp設定は、Vaultwardenからメールを送信できるようにする設定です。gmailアカウントでSMTPメール送信したい場合、こちらが関連記事となります。
Vaultwardenの動作確認
ロードバランサから、192.168.xx.63のIPアドレスが割り当てられました。
VaultwardecのPVCは、既定の容量は1GiBでした。rook-cephの分散ファイルシステムを、デフォルトのPVに設定したため、実際に1GiBのPVが割当られています。
おうちLANの中で、Webブラウザでhttp://にて、ロードバランサから割り当てられたIPアドレスにアクセスします。
Raspberry Piクラスタですが、特に問題なくVaultwardenを起動し、トップページにアクセスできました。
ページは日本語で表示されていて、ログイン前後に何か設定調整は必要ない感じです。
ユーザ作成はSSL接続が必要
「アカウントの作成」リンクから、アカウント情報を入力、作成ボタンを押してみましたが。
画面の右上に「HTTPSが必須」との警告が表示されて、ユーザは作成できませんでした。
そもそも、高品質のセキュリティが必要な、パスワード管理システムを動かすのですから、ここでSSL無効にしてしまうと、セキュリティの品質が損なわれてしまいます。
Kubernetesとは別の、構築したリバースプロキシ機能を持つWebサーバで、SSL化したいと思います。
インターネットホスティング用にCaddyサーバを構築
インターネットへの接続は、別途、RHEL9互換のRocky Linux ９をインストールしたRaspberry Pi 4で行っています。
Rocky Linux 9インストール→IPv4 PPPoE接続→Caddyインストール
Rocky Linux 9にCaddyをインストールしまして、SSL証明書自動更新のWebサーバを構築しました。
WordPressとNextcloudのホスティング設定
複数のサービスを、1つのSSL証明書(ホスト名)でホスティングできるように。
サブディレクトリを作り、該当のサーバにリーバースプロキシとして接続できるようにしました。
具体的には、https://<ダイナミックDNSホスト名>/blogにアクセスするとWordPress。
https://<ダイナミックDNSホスト名>/nextcloudにアクセスするとNextcloud。
今回新たにVaultwardenをホスティングするのですが、サブディレクトリには使用できないため、別の方法でサービスを切り替えます。Caddyは引き続き使用します。
VaultwardenのSSLホスティング設定
Vaultwarden専用のホスト名を取得
今回、Vaultwardenは、スマートフォンのBitwardenアプリからアクセスして使いたいと考えています。
このため、サブディレクトリでサービスを分ける方式ではなく、別のホスト名を割り当てて、そのホスト名を判別してリバースプロキシに割り当てる方式にしようと思います。
使用させて頂いているダイナミックDNSサービスのNo-IPにて、新たに「～vw」というホスト名を作成しました。
既存のホスト名と同じマシンを使用するため、IPアドレス欄は、どちらも同じIPアドレスになります。
どちらの名前でアクセスされたか、を判別して、サービスを切り替えるかたちです。
ダイナミックDNSのIPアドレス自動登録 No-IP 3 DUC設定変更
ダイナミックDNSのホスト名に対するIPアドレスの登録は、こちらのデーモンで行っています。
/etc/default/noip-ducファイルを編集します。
sudo vi /etc/default/noip-duc
NOIP_HOSTNAMESにホスト名を追加しました。
NOIP_HOSTNAMES=<ホスト名１>,<ホスト名2>サービスを再起動して、IPアドレスを登録しました。
sudo systemctl restart noip-duc.service追加したホスト名と、IPv4 PPPoE接続したIPアドレスが合致しているかどうか、先程の画面、no-ipのHostnamesページにて確認します。
Vaultwarden向けCaddyリバースプロキシ設定
Caddyの設定ファイルを編集します。
vi /etc/caddy/Caddyfile
今回新たに４行追加しました。
<Vaultwarden用のホスト名> {
# Vaultwarden
reverse_proxy /notifications/hub <VaultwardenサービスのIPアドレス>:3012
reverse_proxy <VaultwardenサービスのIPアドレス>:80
}画面では35行目以降が、追加した設定になります。
末尾vwのホスト名でアクセスされた場合は、すべて4オクテット目63のIPアドレスへ、リバースプロキシ接続しています。
TCPポート番号3012は、通知用のWebsocket接続になります。ノーティフィケーション・ハブ宛のリクエストは、そちらのポート番号に転送する設定にしました。
情報はこちら、Caddyのコミュニティになります。
[blogcard url=”https://caddy.community/t/vaultwarden-on-docker-with-caddy-to-reverse-proxy/15100″]
TCPポート番号3012による通知は、Vaultwardenに限らず一般的に使用されるため、他のサービスのリバースプロキシ化でも、今後、設定する機会があるかもしれません。
設定変更後、reloadコマンドで反映しました。
sudo systemctl reload caddy.serviceSSLホスティングVaultwardenの動作確認
PCによるアクセス
Webブラウザで、Vaultwarden用のホスト名にアクセスしました。
今度は「アカウントの作成」が問題なくできるようになりました。
URL欄に鍵のマークが付いていて、SSLで通信できています。
証明書の日付を確認すると、先程/etc/caddy/Caddyfileを編集してリロードした時間に、証明書が自動的に作成されたことが確認できました。
証明書は3ヶ月の有効期限、2ヶ月程度で更新されてゆく動きかと思います。(更新頻度はLet’s encryptとCaddyの実装によるため、これは正確な情報ではありません。動きの例になります。
iPhoneアプリによるアクセス
[blogcard url=”https://apps.apple.com/us/app/bitwarden-password-manager/id1137397744″]
アプリをインストールして起動します。
「ログイン先→自己ホスト型」を選択します。
サーバーURL欄に、VaultwardenのURLを入力しました。
ログイン先が「自己ホスト型」に変わったことを確認して、メールアドレスを入力してログインします。
通知や自動同期等の機能も使用できる感じでしょうか。(実際はまだ未確認
無事に保管庫が表示されて、iPhoneにてVaultwardenが使用できる見通しになりました。
データのバックアップが課題
今回、helmによるVaultwardenのインストール時に、PVを有効にしましたが。
helmでVaultwardenをアンインストールしたところ、PVC、PVともに消えています。
つまり、アンインストールすると、データが消えるという動きになります。
同じくHelmでインストールしたWordPressの場合、アンインストールしても永続化ボリュームは残る動きでした。おそらく、チャートの作りの違いが原因と思います。
データのバックアップについては、Kubernetesのノード側から定期的にバックアップできるようにする予定です。
引き続き、研究しますです。
以上のような感じで、KubernetesのVaultwardenを、スマートフォンから使用できるようになりました。
Vaultwardenのデプロイはhelmを使わせて頂いたため、コマンド1行で終わりました。
Caddyのリバースプロキシも、設定を4行追加して完了しました。
残る問題は、データのバックアップでしょうか。
既定のデータベースとしてsqliteを使用しましたが、他にmariadb等を選択可能です。
私個人は、sqliteの選択で特に問題が無いと考えております。取り扱うデータも、それほど大規模ではありませんし、高いレベルのセキュリティを維持したいため、別途データベースのポッドを起動するのはどうかな、という考えに基づいています。
Vaultwardenを本格的に使用するためには、バックアップ体制ができてから。定期的にしっかりバックアップが稼働してから、と考えています。
というわけで、それではまた次回お会いしましょう！[amazonjs asin=”B07TQT6SVY” locale=”JP” title=”実践Helm─自作アプリをKubernetesクラスタに簡単デプロイ！ (技術の泉シリーズ（NextPublishing）)”]
コメントを残す