Linux on 屑籠というかゴミ箱

BitwardenSecretsManagerを使ってみる

Sun, 27 Sep 2026 22:06:56 +0900

概要

最近APIのシークレットを.envとかに入れるのが嫌なので何かしらマネージャー管理にようと考えて候補を検討して、結局パスワードマネージャー同様にBitwardenにして進めてみた。
比較はInfisical。管理上の問題とかでBitwardenを選択。
そのままセットアップしていたところマシンアカウントのアクセストークンを環境変数に直接保存する運用が公式運用となっていたので、ちょっと微妙だなとファイル保存して実行時だけ使用する環境で構築した。
可能であれば暗号保存したほうが良いと思うが、結局それも同じ問題を抱えそうなのでいったんこの方式で使ってみる。

検討した製品・サービス

比較検討

シークレットマネージャーはパスワードマネージャー同様にそれなりに普及してきているので候補は色々ある。
BitwardenSecretsManager（以下BitwardenSM）と比較したのはInfisical。
こちらのほうが大分高機能で色々出来る感じなのとOSS版とクラウド版があって、クラウド版はFreeでも個人なら普通に使えるレベルだった。

調査はChatGPTで調べて公式ドキュメントを参照していった感じ。
ChatGPTまとめで比較としてはこんな感じになった。

条件	Bitwarden SM Free	Infisical Self-host	Infisical Cloud Free
料金	無料	OSS部分は無料	無料
Secret数	無制限	100個超なら問題なし	100個超なら問題なし
Project数	3	無制限	無制限
人間ユーザー	最大2	Identity枠に含む	Identity枠に含む
Machine Identity	3 Machine Accounts	Freeでは人間含め計5 Identityが基準	人間含め計5 Identity
1人利用時のMachine枠	3	おおむね4	4
複数VMから同一Secret取得	○	○	○
2FA	○	○	○
FIDO2/WebAuthn 2FA	○	明示なし	明示なし
パスキーによるログイン	○（Beta）	現行Free仕様では確認できず	現行Free仕様では確認できず
Entra ID SSO	× Enterpriseのみ	Freeでは×	× Pro以上
Audit Log	×	Freeでは×	×
Secret Versioning	Bitwarden方式	Freeでは×	Freeでは×
運用管理	不要	自分で必要	不要
障害・バックアップ責任	Bitwarden	自分	Infisical
データを自宅内に限定	×	◎	×

当初はセルフホストも考えたけど、結局Cloud版とあまり変わらない制限だったので、Infisicalのセルフホスト版は早めに除外してクラウドのBitwardenSMとInfisical Cloudで比較した。
一番大きな違いとしてBitwardenSMはProject数に制限があること、BitwardenSMはWebログインにパスキーが使えること。
BitwardenSMのPlans表にはTwo-step loginのところにそういった記載は無いけれどBitwardenPasswordManager側とWebログインのアカウントが共通なのでパスキーもベータ扱いだけど使える。

こちらももう少し細かくまとめた。

項目	Bitwarden Secrets Manager Free	Infisical Cloud Free
月額	$0	$0
人間ユーザー	最大2	Machine含め合計5 identities
Machine用ID	3 Machine Accounts	5 identitiesの内数
1人利用時のMachine枠	3	実質4
Secret数	無制限	数による上限は料金表に記載なし
Project数	3	無制限
Environment	独立した同等概念なし	3 / Project
Secret Folder	Project中心	○
Secret Reference	基本的なSecret管理	○
Secret Override	―	○
CLI	○ `bws`	○
API/SDKによる取得	○	○
コンテナへの環境変数注入	○	○
Machineごとの権限設定	○	○
Secret Sync	限定的なIntegrations	10 Syncs
2FA	○	○
Entra ID SSO	×	×
SAML SSO	×（Enterprise）	×（Pro）
FIDO2/WebAuthn	Bitwardenアカウントで○	Freeの主要機能として記載なし
Passkeyログイン	○	現状は主要Free機能として記載なし
Audit Log	×	×
Secret Versioning	専用履歴機能としてFreeにはなし	×
自動Secret Rotation	×	×
Point-in-time Recovery	×	×
IP Allowlist	×	×
Freeの主な制約	3 Projects / 3 Machines	5 identities

Project数は自宅の利用ならそんなに必要ないかな？ということで、いったんBitwardenに集約することにした。
駄目なら移行しちゃえばいいし。 AIエージェントが賢くなりすぎて移行がやりやすくなって色々試せるのが最近のいいところ。

InfisicalのOSSセルフホストとCloudFreeの比較

OSSセルフホストもMITライセンス部分が一部ということで機能制限されているようなので、これもChatGPTで条件まとめ。

機能	OSSセルフホスト
Web管理画面	○
Secret保存・取得	○
CLI / API / SDK	○
Machine Identity	○
Universal Auth	○
複数Project	○
Secret Folder	○
Secret Reference / Import / Override	○
Docker / Kubernetes / Terraform等連携	○
Infisical Agent	○
2FA	○
SAML SSO / Entra ID SSO	×
OIDC SSO	×（ライセンス対象）
LDAP	×
SCIM	×
高度なRBAC / Access Control	×
Secret Versioning	×
Point-in-Time Recovery	×
Audit Log	×
Secret Rotation	×
Dynamic Secrets	×
Custom Roles	×
Temporary Access	×
Approval Workflow	×
External KMS / HSM	×
SIEMへのAudit Log転送	×

Bitwarden Secrets Managerセットアップ

公式のスタートアップ説明はこちらSecrets Manager Quick Start

Bitwarden Secrets Managerの有効化

Bitwarden Password Managerを利用しているなら、Webログイン後画面の左下にSecrets Managerへの切替メニューがあるのでそこを選択して、組織名とPlanを設定して有効化。
有効化するとWebログイン後、Password ManagerとSecrets Managerの切替メニューが左側のサイドメニュー下側に現れるようになるのでそこで、そこで切り替える。

ユーザーのロール設定

Admin Consoleでメンバーを選択し、シークレットマネージャー利用ユーザーのメンバーロールを編集して一番下にある「このユーザーはシークレットマネージャーにアクセスできます」のチェックをONにしておく。
自分の場合は一人で管理者だけなので最初からチェックついていました。

Projectの作成

最初にProjectを作成する。
FreePlanでは3Projectまでなのでどうしようか迷ったけど

applications
infrastructure
other あたりにしておく。
BitwardenSMのFreePlanでは分類がやりにくい問題はあるので、分類するほどシークレットが多い場合はInfisical Cloudのほうが良さそう。

マシンアカウントの作成

シークレットのアクセスを自動化するためにマシンアカウントを作成する。
これも3アカウントに限定されるので、必要があれば機能別に分けるようにするつもりだけどいったんは1アカウントで様子見する。
作成したマシンアカウントに先ほど作成したProjectを割り当て。
とりあえず読み取り専用で登録。

Secrets Manager CLI(bws)のインストール

公式のドキュメントはこちらSecrets Manager CLI
テストでインストールしたマシンの条件はこちら

1
2
3
4


Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.5 LTS
Release:	24.04
Codename:	noble

Linuxなので

1

sudo curl https://bws.bitwarden.com/install | sh

としたら

1

unzip is required to install bws.

と指摘されたので先に入れておく。正常にインストールしたらバージョン確認

1
2


$ bws --version
bws 2.1.0

アクセス

マシンアカウントのアクセストークンを使用してアクセスする。
マシンアカウントでアクセストークンを作成し、環境変数に設定するのが公式の設定。

1

export BWS_ACCESS_TOKEN=<アクセストークン>

しかしアクセストークンを環境変数に与えるのはなんか嫌だ。
ということで、bwsグループを作ってこのグループに参加しているユーザのみトークンファイルを読めるようにしておいて、コマンド実行時にそこから実行時に環境変数に値を入れるようにする。
環境には残さないようにしたラッパー経由でbwsコマンドにアクセスするようにする。

1
2
3
4
5
6
7


sudo groupadd --system bws
sudo mkdir /etc/bws
sudo vi /etc/bws/access-token
sudo chown root:bws /etc/bws/access-token
sudo chmod 640 /etc/bws/access-token

sudo usermod -aG bws $USER

その後、ラッパー用のスクリプトをユーザーローカルに作成する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


mkdir -p ~/bin

cat > ~/bin/bws <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

# 万一呼び出し元でxtraceが有効でも、Secretを出力させない
set +x

readonly REAL_BWS="/usr/local/bin/bws"
readonly TOKEN_FILE="/etc/bws/access-token"

if [[ ! -x "$REAL_BWS" ]]; then
 printf 'bws wrapper: executable not found: %s\n' "$REAL_BWS" >&2
 exit 127
fi

if [[ ! -r "$TOKEN_FILE" ]]; then
 printf 'bws wrapper: token file is not readable: %s\n' "$TOKEN_FILE" >&2
 exit 126
fi

BWS_ACCESS_TOKEN="$(<"$TOKEN_FILE")"

if [[ -z "$BWS_ACCESS_TOKEN" ]]; then
 printf 'bws wrapper: token file is empty: %s\n' "$TOKEN_FILE" >&2
 exit 1
fi

export BWS_ACCESS_TOKEN

exec "$REAL_BWS" "$@"
EOF

chmod 700 ~/bin/bws

再ログイン後、おそらく自動で優先的なパスとして選択してくれるので以下で確認。

1

type -a bws

/home/user/bin/bwsが最優先になっていればOK

docker-compose起動用のスクリプトの作成

当初の目的のメインがdocker composeの.envファイルに秘密情報を書かないようにする、なのでdocker composeで利用できるようにする。
普段行っているように

1

docker compose up -d

とすると、bws runと組み合わせられない。
しかし組み合わせる場合オプションにProjectIDをつけることになるとすると毎回UUIDを引っ張ってくる必要があって面倒くさいので、起動用のスクリプトを作成する。

以下のような感じで作成した。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


#!/usr/bin/env bash
set -euo pipefail

readonly PROJECT_ID="プロジェクトID"

exec bws run --project-id "$PROJECT_ID" -- '
 : "${SERVICE_TOKEN:?SERVICE_TOKEN is not set}"

 export TOKEN="$SERVICE_TOKEN"
 unset SERVICE_TOKEN

 exec docker compose up -d
'

これを実行できるように権限を与えて

1
2


chmod 755 compose-up
./compose-up

で実行させるようにした。
終了はこれまで通りdocker compose down。
課題として、compose.yamlで配列として環境変数を渡している場合、終了時に環境変数がないとワーニングが出て嫌なので

compose.yamlの環境変数の渡し方はリストにして直接指定する
BitwardenSMに登録している環境変数名とコンテナに渡す環境変数が違う場合はcompose-upのexportのところで変換してやるという形で対応した。

systemd-credsによるAccessToken暗号化

先程までの方法だと、マシンアカウントのAccessTokenが残るじゃないかと思って色々考えていたけど、systemdと連係をするのであればsystemd-credsが使用できる。

1
2
3
4
5
6
7
8


sudo install -d -m 700 /etc/credstore.encrypted

systemd-ask-password -n "BWS Access Token:" |
sudo systemd-creds encrypt \
 --with-key=host+tpm2 \
 --name=bws-access-token \
 - \
 /etc/credstore.encrypted/bws-access-token

これを実行するとトークンの入力を聞かれるので入力すると/etc/credstore.encrypted/bws-access-tokenに暗号化した状態でトークンを保存してくれる。
そして鍵情報はTPMを利用しているので、Proxmox使っている場合はvTPMを割り当てている必要がある。今回作った。

確認方法

1

sudo systemd-creds decrypt /etc/credstore.encrypted/bws-access-token -

ただし、こちらはroot権限が必要になるのでユーザ権限で起動するようなroot-less運用している場合は

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


mkdir -p ~/.config/credstore.encrypted
chmod 700 ~/.config/credstore.encrypted

systemd-ask-password -n "BWS Access Token:" |
systemd-creds encrypt \
 --user \
 --with-key=host+tpm2 \
 --name=bws-access-token \
 - \
 ~/.config/credstore.encrypted/bws-access-token

としてCredentialファイルを作成する。
そしてこれを使ってSystemdのUnitファイルを修正して実行したとこNG。
調べてみたらsystemd 257のバグらしくユーザーサービスとしてLoadCredentialEncryptedとかが使えないようで258で修正予定とのこと。

As of systemd 257, the ImportCredential, LoadCredential, LoadCredentialEncrypted, SetCredential and SetCredentialEncrypted settings do not work in user services. This should be fixed by [1] in systemd 258.

引用元

じゃあsystemサービスとしてUnit移行させてそこからユーザーサービスとして起動させるか？と思ったけど、将来Quadletに移行しようとした場合はsystemサービスのUnitからユーザーサービスとして起動できないみたいなので、移行してさらに移行みたいなことをしないといけなさそうなのが面倒。
ということで一旦Podman管理のサービスは後回しにすることに。

immichにEntraIDログインする

Sat, 12 Sep 2026 22:02:11 +0900

今回の構成

ImmichはPodmanのコンテナで稼働
EntraID Freeのテナントを利用
Immichの名前解決とアクセスにはCloudflare One／WARPが必要
EntraIDは自分のテナントのユーザーだけが対象
LAN内の別アドレスではOAuthがうまく動作しないため、パスワードログインも残す

1
2
3
4
5
6
7


普段のアクセス
端末 → Cloudflare One／WARP → Immich
 ↕ OIDC
 Microsoft EntraID

LAN 内のアクセス
端末 →Immichのローカルアドレス → メールアドレス＋パスワード

Immich の設定画面では「OAuth」と表記されているが、ユーザー認証には OpenID Connect（OIDC）の利用になる。
Immich 公式：OAuth Authentication

プライベートなサーバーの認証

認証後にImmichのリダイレクト URI に戻るのはユーザーのブラウザになる。EntraIDからImmichへの直接の接続は必要ない。
ただ、ブラウザはEntraIDとImmichの両方に、Immich Server はEntraIDの認証エンドポイントにアクセスできる必要がある。
Microsoft 公式：OpenID Connect

このため、WARP接続中のブラウザから名前解決できて信頼できる証明書でHTTPS接続できることが前提になる。

EntraID のリダイレクト URI は localhost などの例外を除きHTTPSが必要になる。
Immich のドキュメントにローカルIPのHTTP例があっても、それをそのままEntraIDに適用できるとは限らないということで.localのようなケースはダメそう。 Microsoft 公式：リダイレクト URI の制約

EntraID にImmich用のアプリを登録

Microsoft Entra 管理センターで次の順に開く。

1

EntraID → アプリの登録 → 新規登録

項目	設定例
名前	`Immich`
サポートされているアカウントの種類	この組織ディレクトリ内のアカウントのみ（シングルテナント）
リダイレクト URI のプラットフォーム	Web
リダイレクト URI	`https://immich.example.com/auth/login`

登録後、概要画面から以下を控える。

アプリケーション（クライアント）ID
ディレクトリ（テナント）ID

リダイレクト URI の追加

アプリの「認証」で、Web のリダイレクト URI に以下を登録する。

1
2
3


https://immich.example.com/auth/login
https://immich.example.com/user-settings
https://immich.example.com/api/oauth/mobile-redirect

用途は順に

Web ログイン
既存アカウントへの OAuth のリンク
モバイルアプリへの認証結果の受け渡

モバイルでは HTTPS の中継先から app.immich:///oauth-callback に戻す。
Immich 公式：リダイレクト URI、モバイル用リダイレクト

ブラウザで実際に開くホスト名と、登録したURIをそろえる。別名でアクセスする場合は、そのURIも登録対象になる。

クライアントシークレットの作成

1
2
3
4
5


アプリの登録
 →Immich
 → 証明書とシークレット
 → クライアント シークレット 
 → 新しいクライアント シークレット

作成後に表示される 「値（Value）」 をImmichに設定する。「シークレット ID」ではないので注意。
値は作成直後にしか表示されないため、分からなくなった場合は新しいシークレットを作成する。
Microsoft 公式：クライアントシークレットの作成

利用するユーザーの割り当て

自分のユーザーだけに利用を限定するため、エンタープライズアプリケーション側で設定する。

1
2
3
4
5


EntraID
 → エンタープライズ アプリケーション
 → Immich
 → プロパティ 
 → 割り当てが必要ですか？ → はい

続いて、「ユーザーとグループ」から利用するユーザーを直接追加する。割り当てを必須にしたアプリには管理者による同意が必要になる。
Microsoft 公式：ユーザーとグループの割り当て

ただしGlobal Administrator は割り当て必須の制限の例外であることに注意。
管理者ユーザーでログインできただけでは、未割り当てユーザーの拒否を確認できない。アクセス制限の検証には通常ユーザーを使う必要がある。
Microsoft 公式：エンタープライズアプリケーションのプロパティ

OAuth profile does not have an email address：メールアドレスがない

このまま続けていて、エラーが発生したのでメモ。メールアドレスの設定をしておく必要がある。
発生したエラーは以下

1

OAuth profile does not have an email address

Immichの新規OAuthユーザー登録では、プロファイルの email が必要になる。
preferred_username がメールアドレスのような文字列でも、その値で email を代用する実装にはなっていない。
Immich ソース：認証サービス

まずImmichの Scope が openid email profile になっているか確認する。そのうえで、EntraIDのアプリ登録に email のオプション要求を追加する。

1
2
3
4
5
6


アプリの登録
 →Immich
 → トークン構成
 → オプションの要求を追加 
 → トークンの種類：ID
 → email を選択 → 追加

設定方法は Microsoft 公式：オプション要求の構成を参照。

現行の開発ブランチでは、ImmichはIDTokenに email があればそのclaimsを使い、なければUserInfoを問い合わせる。
どちらからもメールアドレスを取得できないと、新規登録に進めない。Immich ソース：OAuth リポジトリ

ということで、メールアドレスをちゃんと設定しておく必要がある。
EntraIDのユーザ設定でプロパティを見ると、連絡先情報項目に「メールアドレス」があることがわかる。
ここに使いたいメールアドレスを入れておく必要がある。

Immichの OAuth を設定する

Immichの管理画面でAdministration → Settings のOAuth Authenticationで設定。
今回の構成で使う値は以下。

項目	設定値
Enabled	ON
Issuer URL	`https://login.microsoftonline.com/<TENANT-ID>/v2.0`
Client ID	アプリケーション（クライアント）ID
Client Secret	作成したシークレットの「値」
Scope	`openid email profile`
ID Token Signed Response Algorithm	`RS256`
Userinfo Signed Response Algorithm	`none`
Storage Label Claim	`preferred_username`
Button Text	`Login with EntraID`
Auto Register	ON
Auto Launch	OFF
Mobile Redirect URI Override	有効にして下記 URI を指定
Mobile Redirect URI	`https://immich.example.com/api/oauth/mobile-redirect`

設定項目と標準値は Immich 公式：OAuth の有効化を参照。画面によって署名アルゴリズムの項目名は異なる。

Issuer URL の <TENANT-ID> は実際のテナント ID に置き換える。EntraIDの管理画面を見ればわかるのでそちらを参照。
Discovery 文書の URL は次になる。

1

https://login.microsoftonline.com/<TENANT-ID>/v2.0/.well-known/openid-configuration

今回はシングルテナントなので、common や organizations ではなく、テナント ID を明示する。Microsoft 公式：OIDC の構成文書

OAuthで登録したユーザーをImmichの管理者にする

自動登録されたユーザは管理者になっていないので、管理者として使いたい場合は元の管理者ユーザでログインして管理者権限を付与する必要がある。
管理者でログインして「管理」→「ユーザー」→「対象のユーザー」→「編集」

OAuthで登録したユーザーのパスワードログイン

OAuthで登録したユーザーはパスワードログインが出来ない状態なので、ローカル環境からログインするためにパスワードログインできるように設定する。
元の管理者ユーザーでログインしたうえで「管理」→「ユーザー」→「対象のユーザー」→「パスワードをリセット」を実行すると、パスワードリセットしたうえでランダムパスワードが提示されるのでこれを使ってパスワードの再設定を行う。

ログイン画面

ログイン画面にOAuthログイン用の「Login with EntraID」を追加した形になりました。

バックアップツールの見直し（rsnapshotからBackrestへ切替検討）

Sat, 12 Sep 2026 16:38:45 +0900

これまでLinuxサーバーのバックアップにはrsnapshotを使っていましたが、GUIで設定出来るようにしたいとか外付けHDDを必要なときだけ接続してバックアップ出来るようにしたいとかあって、バックアップツールの見直しを検討。
色々比較したけど扱いやすそうなresticをBackrestで操作するのを基本にしようと環境を構築してみた。

ツール

Backrest

Backrestは、resticをWeb GUIから操作するための管理ツール。
バックアップ処理自体はresticが行ってその管理をBackrestが行う形式。

バックアップジョブの設定
スケジュール管理
保持世代の設定
prune/checkなどのメンテナンス
スナップショットの確認
復元

をGUIで行える。
復元も一括操作くらいなら大丈夫そうだけど、個別の世代のファイルを検索かけながら見つけて復元するような使い方は結構難しそうだったので復元が必要な場合はresticを直接CLIで操作してやることで対応する想定。

restic

機能として以下のようなものがあり、rsnapshotではハードリンクで対応していた世代重複の排除をブロック単位での重複排除で出来るようになっているみたい。

暗号化
重複排除
圧縮
スナップショット管理
世代管理
リポジトリ整合性チェック
ローカルディスク、SFTP、S3など多様な保存先への対応

圧縮に関してはあまり期待していない。というのもバックアップ対象が圧縮済みのものが多いのでおそらくほとんど差がでないはず。

独自形式で保存されるけど、restic mountコマンドでスナップショットをディレクトリにマウント出来る。マウントして中身を通常のシェルから操作可能な状態に出来るのでrsnapshotとそんなに変わらない感覚でファイル単位での復元も可能そう。

インストール

バックアップ用Docker

今回は以下の方針

バックアップ用にBackrestをDocker（Docker compose）で構築運用
リストアようにホスト側にresticを入れる

Backrestは公式のGitHubページを参照して、公式のDocker composeファイルの記載内容を少しだけ修正して実行。

以下が公式に挙がっているcomposeファイルの内容だけど

Volumesの特にバックアップ対象と、出力先のマウント設定
TZ設定

あたりだけ修正して実行すれば良い。
バックアップ用としてrootで起動したいのでユーザは指定しない。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


services:
 backrest:
 image: ghcr.io/garethgeorge/backrest:latest
 container_name: backrest
 hostname: backrest
 volumes:
 - ./backrest/data:/data
 - ./backrest/config:/config
 - ./backrest/cache:/cache
 - ./backrest/tmp:/tmp
 - ./backrest/rclone:/root/.config/rclone # Mount for rclone config (needed when using rclone remotes)
 - /path/to/backup/data:/userdata  # Mount local paths to backup
 - /path/to/local/repos:/repos  # Mount local repos (optional for remote storage)
 environment:
 - BACKREST_DATA=/data
 - BACKREST_CONFIG=/config/config.json
 - XDG_CACHE_HOME=/cache
 - TMPDIR=/tmp
 - TZ=America/Los_Angeles
 ports:
 - "9898:9898"
 restart: unless-stopped

ホスト用restic

ホスト用のresticはUbuntu 24.04LTSなのでaptで入れてもいいんだけど、aptで入れるとかなり古いバージョンになってしまいBackrestのdockerでlatestにするとバージョンがかなり違うため相性問題が出ると嫌なので、最新のバイナリをインストールしておく。
バイナリは公式からDLしてインストール。

1
2


sudo install -m 0755 restic /usr/local/bin/restic
restic version

でインストールしてバージョンが表示されればOK。

restic mountを使えるようにするにはfuseがインストールされている必要があるということなのでこれはaptで入れておく。
自分の環境では入っていた。

1

which fusermount

でなければ

1

sudo apt install fuse3

で良いらしい。

バージョンを上げたい場合は、

1

sudo restic self-update

でアップデート出来るらしいので、次回からはバイナリを探しに行く必要は無いみたい。

設定

docker composeで起動したらブラウザからアクセスすると各種設定を要求されるので適当に入れておく。

バックアップの設定としては、まずバックアップの保存先の指定として「リポジトリ」を作成する。そしてバックアップ元の指定とかスナップショット件数の設定とかは「プラン」で指定・作成する。試していないけど一つのプランで複数のパスが指定できるので、一つのリポジトリに対して複数のバックアップ元を指定することも出来るはず。

その他、プランごとに実行タイミングを変えられるので、一つのリポジトリを対象に複数のプランを設定することも可能なはず。現時点では必要なくて試していないけど。

バックアップデータのマウント

バックアップしたデータをシェルからアクセス出来るようにするには

1

sudo restic -r /snapshot_path mount /mnt/restic

でマウント出来る。
実行後、リポジトリを作成した際に設定したパスワードを要求されるので入力するとマウントされる。注意点として、実行中しかアクセスできないので別ターミナルを開いてアクセスするとかの工夫は必要。

Docker Composeファイルを見ればわかるけれど標準だとrootで実行されるため、バックアップデータはrootで保存される。なので、マウントするときにはsudoが必要だし、マウント後にファイルアクセスするにもsudoが必要。
いくつか対策は考えられるけど、rootで管理したほうがいいとは思うので問題がなければこのまま運用してみる予定。

今後に向けた備考

8TBのHDDが4台？5台？ほど余っているので、定期的に外にバックアップするようにしたい。

このような環境の場合、間違ってマウントされていない状態でマウントポイントにバックアップしてしまうのを防ぐ必要があるので、Backrestのhook処理に

1

mountpoint -q /mnt/backup-usb || exit 1

みたいな感じでマウントの確認チェックを入れておく必要がある。
リポジトリの以下の部分にこの手の設定を入れればいいはず。

セルフホストのimmichをCloudflare環境で100MB制限を回避する

Mon, 07 Sep 2026 19:15:50 +0900

immich

Google Oneを100GBで契約しているけどAIプランを使うつもりが無いのでストレージ容量を結構気にしないといけない感じになっている。
画像のアップロード場BAN対象になりやすそうなのもあり、セルフホスト出来るGoogleフォト代替のimmichを試してみる。

Cloudflareの公開アプリケーションにおける制限について

Cloudflareではプロキシトラフィック1ペイロードあたりの制限がプランごとに決まっていて、Freeプランでは100MBに制限されている。Error 413

画像であれば基本的に問題ないのでimmichで問題になることはあまりないかな？と思っていたけど動画を扱うと一瞬で100MBくらいは飛ぶのでできるだけ回避しておきたい。

方針

以下のような構成を想定して構築する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


スマートフォン
Cloudflare One Client / WARP
 │
 │ 認証済み端末
 ▼
Cloudflare Zero Trust
 │
 │ Private hostname route
 ▼
cloudflared（自宅）
 │
 ▼
Immich
192.168.x.x:2283

Cloudflare Zero TrustのPrivate hostname routeで公開せずにCloudflare Oneの認証を利用してアクセスする方式にする。
ドキュメントを見ると以下の記載があり、1ファイルが大きい場合はPrivate network routeを使用するように記載がある。Routing

1
2


Public hostname routes proxy traffic through Cloudflare. On Free, Pro, and Business plans, the service-specific terms ↗ require you to use a specific paid service to serve video and other large files.
Refer to Delivering videos with Cloudflare for more information. To transfer large files privately, use a private network route instead.

Private networkについてはCloudflare One経由でのアクセスに限定されるけれど、現状CloudflareAccessの認証でOne/WARP利用を条件にしているので、使い勝手としては変わらないはず。
自分以外、もしくは家族とか特定の人以外がアクセスしないような環境であればこの方法で問題ないはず、ということでこの方法で進める。
そしてPrivate Hostname Routeについては先月一般提供始まった機能らしいので、これを使ってみる。

構成環境

概要

環境としてはRHEL10のPodman環境で構築する。
想定している構成は以下のような感じでtunnel用のcloudflaredをDMZ環境にしてリバースプロキシでやり取りする。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


 Cloudflare
 │
 Immich Tunnel
 │
 ▼
┌────────── Immich VM ────────────────┐
│ │
│ Podman network: immich-edge │
│ │
│ cloudflared ─── Reverse Proxy │
│ │ │
│ ─────────┼──────── │
│ │ │
│ Podman network: immich-app │
│ │ │
│ Immich Server │
│ │ │
│ PostgreSQL / Valkey │
│ │
└─────────────────────────────────────┘

最終的にimmichはEntraIDログインを強制するように出来るようなので、そのようにすることでパスワードを個別に管理することもしないことにする。

使用サービス

以下の構成で検討。

edge
- cloudflared
- caddy
app
- immich-server
- postgres
- valkey

データ自体はNASのHDDに置くようにして、その他はSSDで管理するように。
NASからVMまではNFSで共有。

Cloudflare Zero Trust設定

いくつかの設定はあるけれど基本的には

tunnelの追加
プライベートホストのルート設定を追加
Accessのアプリケーション設定の追加

といった感じでいく。
後述するけどプライベートホストの名前はTLSで通信するための証明書を確保しようとする場合は保有するドメイン名で適当につける。

Cloudflare APIの設定

TLS用の証明書確保のためLet’s Encriptを使うのだけれど、ローカルのIPアドレスのためDNS-01を使用する。そのために更新用のCloudflareでAPI設定をする必要がある。

アカウントの管理
→ アカウントAPIトークン
→ トークンを作成
→ 最初から作成
→ 対象を「指定ドメイン」にして対象を指定
→ DNS & Zone

1
2


DNS：Edit 
Zone： Read

に設定する。
このときのAPIトークンを使用する。

必要なトークンは一度しか表示されないので、記録を忘れたら作り直し。
DNS-01の解説はこちらにありました。ホームサーバーの自己署名証明書を Let’s Encrypt の DNS-01 に変更し、自動配布まで行う

Caddy

Docker構成

DockerHubにある標準？のCaddyだとCloudflareのDNS-01に対応していない？らしいのでCodexにDocerfile書いてもらった。

dockerfile

1
2
3
4
5


FROM docker.io/library/caddy:2-builder-alpine AS builder
RUN xcaddy build --with github.com/caddy-dns/cloudflare
FROM docker.io/library/caddy:2-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
COPY Caddyfile /etc/caddy/Caddyfile

Caddyfile

リバースプロキシとして使用するCaddyがこのあたりの仕組みに対応しているようなので、Caddyfileに書いてしまう。

caddifile

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
	email {$ACME_EMAIL}
	acme_ca https://acme-v02.api.letsencrypt.org/directory
	auto_https disable_redirects
}

https://{$IMMICH_PRIVATE_HOSTNAME} {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
		resolvers 1.1.1.1
	}

	reverse_proxy immich-server:2283
}

ACME_EMAILやIMMICH_PRIVATE_HOSTNAMEは.envでまとめる感じで。
先ほど設定したトークンはCF_API_TOKENに指定する。

テスト

アクセステスト

Cloudflare OneをONにした状態でアクセス出来るか確認してOKなら、その後Cloudflare OneをOFFにしてアクセスできないことを確認する。
ついでに、ローカルからはTLSなしのhttpでアクセスすることにしたのでそういう環境で。
immichのアプリ設定を見たところ、SSIDでローカル切替が出来るようなのでこれを利用してみたけど他のアプリと同様にVPN設定しているとWifiのSSID検出ができないようでうまくいかない。
Cloudflare OneをOFFにしたら超高速でアップロードできたので、ちゃんとローカルと外部で切替はできている模様。
やっぱりインターネット回線を10Gbpsにしたいな。
10Gbpsでつながればゼロトラストな考えでローカルネットワークの通信も大半を一度インターネット側に渡しても良くなる気がする。

大容量転送

この状態で起動して初期設定をしたあと、スマホで2分くらいの動画撮影してCloudflare経由で転送して問題ないことを確認する。
300MBちょいのファイルを問題なく転送できたので、想定通りの動作をしている。