Software

[HTTPS化] Bitwarden を Docker で構築できた！ その４ [vaultwarden]

投稿日：

前回うまくいかなかった Bitwarden(vaultwarden) on Docker の https対応について、
オレオレ証明書ではなく、ちゃんとした https 化ができたのでまとめてみる。

 

 

これまでのおさらい

少し間が空いたので、これまでのおさらいをば。

 

環境

第二回より引用。

一つ大きな前提条件は、今回 vaultwarden の dockerコンテナを走らせるホストマシンは、
外部公開されていない、ローカルネットワーク(イントラネット？) 上にある。
どうしても外からアクセスしたいときは、VPNやSSHトンネルなどを介して行う。
このあたりの境界条件が、ネットで見つかる vaultwarden/bitwarden_rs の各種導入記事とは異なることに注意。

Google Adsense



これまでにできたこと

通称 "オレオレ証明書" を用いた https化。

 

実用上の課題

"オレオレ証明書" では iOS版クライアントから接続できない。
そのほか、自動更新された比較的新しいブラウザ拡張からも接続できないようだ。

 

やりたいこと

Let's Encrypt を用いてまともに https化する。
前述のように当該環境は外部公開されていないため、通常よく使われる HTTP-01 チャレンジ は使えない。
代わりに DNS-01 チャレンジ で認証を行う。

 

vaultwarden + caddy on docker

基本的には１つのとあるハマりどころ以外は前回同様のつもりではあるが、
念の為に各ステップを確認しながらやり直したため、
一部、バージョンが上がっていたり設定の追加があったりする。
この差異が影響している可能性は否定できないため、
ハマりどころに加えて、構築手順の詳細も後述する。

 

ハマりどころは？

ログにいくつかそれっぽいものが出ているものの、本質的なエラーは以下でした。

could not find the start of authority for _acme-challenge.xxxx.duckdns.org.: NXDOMAIN

Google Adsense



duckdns に自分で登録したドメイン名に対して DNS-01 チャレンジを行おうとするわけですが、
肝心の目的のドメイン名の名前解決に失敗しているということです。
ホスト側で TXレコードも含めて解決ができていることは別途確認していたので素通ししてっしまっていました。
この "ホスト側" というのがミソで、コンテナ内に入って確認すると名前解決できていませんでした。

 

実際にやったこと

ベースは前々回のセットアップを参照。
DuckDNS の設定は完了している。
vaultwarden 公式の Caddy with DNS challenge にある docker-compose.yml を元にして、
通称 "オレオレ証明書" で動作していた時点を起点としている。
変更点は以下。

  • vaultwarden の docker image の更新 (v1.21 → v1.27)
  • UDP バッファサイズの拡張
  • caddy バイナリの更新
  • コンテナ内での名前解決対応

上記項目の一部について詳細を以下に述べる。

 

UDP バッファサイズの拡張

caddy が以下のようなログを吐いていた。

caddy | {"level":"info","ts":1673852788.23172,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details."}

$ sudo sysctl -w net.core.rmem_max=2500000 で UDP バッファサイズを拡張すると吐かなくなった。

 

コンテナ内での名前解決対応

上記で示したように、duckdns に自分で登録したドメイン名の名前解決がコンテナ内で失敗していました。
私は、コンテナ内の /etc/resolv.conf をホスト側にコピーして DNS として 8.8.8.8 などを追加して、
コンテナ内に共有して見せることで名前解決が通るようになりました。
具体的には以下の通り。

Google Adsense



 

これで無事に Caddy による Let's Encrypt の DNS-01 チャレンジが通って、
duckdns に登録したイントラネット(ローカルネットワーク)上のマシンを正しく(?) HTTPS化させることができ、
自前の Bitwarden (vaultwarden) へ各種クライアントから安全に問題なく接続できるようになった。

 

応用

今回の Caddy による Let's Encrypt の DNS-01 チャレンジ成功によって、
自機に正式なサーバー証明書などを手軽に簡単に発行できないヒラ開発者でも、
ローカルネット or イントラネット上において https 化が比較的容易にできるようになった。
これにより最近の https を標準で要請, 或いは強制する各種サービスも手元で簡単に動作させることができる。
実際にまともな https化 でご利益があったものは以下。

  • Docker registry server
  • Visual Studio Code Server (+ JupyterLab/Hub)
  • Nextcloud

この辺りについては後から別途記事にする予定だが、この https化 のご利益の概要は以下の通り。

 

Docker registry server

Docker Hub 的なものを自分でオンプレに立てられる Docker registry server。
ただし docker pull/push はデフォルトで https 接続を必要とする(*) ので、
今回の Caddy + Let's Encrypt (DNS-01 challenge) による https化で、
特に意識せずとも容易にお手製の docker registry に push/pull できるようになった。

(*) 実際には insecure-registries を設定することで http接続でも通るようになるが、

  • docker registry に non-expert を含む色んな人に接続させる
  • ノートPC などでで先から VPN や SSH-tunnel を介した場合などに見せ方や設定が変わり得る

ということを考えると、Caddy + Let's Encrypt (DNS-01 challenge) による https化は相応にメリットが大きい。

Google Adsense



Visual Studio Code Server (+ JupyterLab/Hub)

Visual Studio Code Server を JupyterLab/Hub と連携させようとしたが、
(localhost 動作ではなく、かつ) 非https 環境では、Jupyter拡張など VScode 拡張の一部が動作しないようだ。
かといって、"オレオレ証明書" でなんちゃって https化すると、
VScode-server 自体が不審がって接続してくれなくなった。
(少なくとも coder版 ではそのような動作になった)

今回の Caddy + Let's Encrypt (DNS-01 challenge) による https化で、
JupyterLab/Hub + VScode-server で期待通りの動作をするようになった。

 

Nextcloud

閉じたイントラネット内であっても、アカウントの id/pwd のみならず、各種データを平文で通すことに抵抗があり、
これまでは自分用ローカルネット内に限定して利用していたが、
今回の Caddy + Let's Encrypt (DNS-01 challenge) での https化により、
イントラネット内にこのサービスを開放してどこからでも接続, 同期できるようにした。
このことによる利便性の向上は言及するまでもないだろう。

 

 

Google Adsense

Google Adsense

-Software
-, , , , ,

Copyright© HEPtech, 2024 All Rights Reserved.