JellyfinのシークレットがComposeファイルやバックアップに漏洩するのを防ぐ方法
Composeファイル、Gitリポジトリ、バックアップアーカイブを、Jellyfinの認証情報を保存する同等の場所として扱わないでください。デプロイ手順は広くコピーされる可能性がありますが、シークレット値には、より限定されたライフサイクル、アクセス境界、復旧経路を設定すべきです。
Jellyfinスタックの機密情報には、APIキー、リバースプロキシやトンネルの認証情報、DNSプロバイダーのトークン、バックアップリポジトリのパスワード、暗号化キー、補助サービスのデータベース認証情報、プラグインや自動化で使用するその他のトークンなどが含まれます。まずそれらを一覧化し、再現可能にすべきもの、復旧可能にすべきもの、単に再発行すればよいものを判断してください。
シークレットの参照と値を分離する
Composeは宣言的に保ちましょう。サービスイメージ、ネットワーク、マウント、ポート、変数名、シークレット参照はファイルに記述し、認証情報そのものは記述しないでください。BACKUP_PASSWORDのようなプレースホルダーなら、Composeファイルを認証情報ストアに変えることなく、要件を明示できます。
平文の環境変数ファイルは便利ですが、ソース管理、トラブルシューティング用の一式、暗号化されていないバックアップへ簡単にコピーされてしまいます。最新のDockerのシークレット管理に関する詳しい解説では、ビルド時のイメージへの漏えい、ローカルの.envファイルの乱立、実行時の環境変数への露出を区別しています。これらは、同じ認証情報漏えいに至る別々の経路です。
シークレットマネージャー、Composeがサポートするシークレットファイルの仕組み、または依存するサービスに適した別の実行時注入方法を使用してください。すべてのJellyfin設定が_FILE規約をサポートしているとは限りません。ファイルベースの注入は、対象のコンポーネントが明確にサポートしている場合にのみ使用してください。
シークレットがイメージ、リポジトリ、シェル履歴に入らないようにする
ローカルのシークレットファイルを、バージョン管理とDockerのビルドコンテキストの両方から除外してください。.gitignoreに記載しただけでは、.dockerignoreで許可されている場合に、広範なDockerfileのCOPYによってそのファイルがイメージに配置されるのを防げません。
長期間有効な認証情報を、シェル履歴に保存されるコマンドラインへ直接渡さないでください。起動時のデバッグでシークレットをエコー出力しないでください。問題の診断に単一の変数で十分な場合は、展開済みの環境変数全体をチケットや共有チャットに出力することも避けてください。
漏えいが疑われる場合、最新のComposeファイルから該当行を削除するだけでは対処になりません。露出した認証情報をローテーションし、可能であれば古いトークンを無効化し、リポジトリとイメージの履歴を調査し、漏えいした値を今後のバックアップや診断情報から削除してください。
必要なシークレットは復旧可能にしつつ、気軽に読めないようにバックアップを設計する
一部のシークレットは復旧に必要です。リポジトリのパスワードや復号キーが同じサーバーとともに失われれば、暗号化バックアップは役に立ちません。また、復元したプロキシや自動化のスタックで、Composeのレシピだけからは再構築できない認証情報が必要になることもあります。
実用的なセルフホスティングの復旧インベントリでは、キー、トークン、リカバリーコード、バックアップパスワードを復旧に必要な主要情報として扱いながら、バックアップ対象のサーバーとは別の場所にバックアップのロックを解除するキーを保管します。これは、平文の.envファイルをすべてのアーカイブに入れることとは異なります。
必要な認証情報ごとに、名称、所有者、正式なコピーの保管場所、復元または再発行の方法、解除できるバックアップを記載したシークレット復旧マニフェストを作成してください。機密情報は、家庭内で適切なアクセス制御を設定した暗号化パスワードマネージャー、暗号化バックアップセット、または分離された保護済み復旧パッケージに保存します。
ログやトラブルシューティング用ファイルを第2のシークレットストアにしない
プロキシのリクエストURL、環境変数のダンプ、アプリケーションのデバッグ出力、シェルの記録には、Composeが適切に管理されていてもトークンが含まれることがあります。ログを共有する前に、認証ヘッダー、APIキー、クエリ文字列内のトークン、Cookie、非公開ホスト名、認証情報を検索してください。
ログに関するガイダンスでは、テレメトリをシステム外へ送る前に機密フィールドをマスキングすることが推奨されています。ホームサーバーのサポート用ファイルにも同じルールを適用しましょう。診断に必要なら元データをローカルに保管し、共有するのはマスキング済みのコピーにしてください。
バックアップの読み取り権限とログの読み取り権限は分けてください。メディアのバックアップを読める人が、DNSトークンやリバースプロキシの認証情報にも自動的にアクセスする必要はありません。シークレットの露出は、ファイル形式の問題であると同時に、アクセス範囲の問題でもあります。
漏えいテストと復旧テストを一緒に実施する
識別しやすい偽の値を持つカナリアシークレットを作成してスタックをデプロイし、Composeディレクトリ、イメージ履歴、コンテナの検査出力、ログ、バックアップカタログ、テスト復元で展開したデータから、その値を検索してください。これにより、実際の認証情報を危険にさらすことなく、現在のワークフローがどこでシークレットをコピーしているかを明らかにできます。
続いて逆方向のテストを行います。文書化された復旧用の資料だけを使用して、分離した環境にJellyfinスタックを復元してください。復旧に失敗したホスト上にしか存在しない認証情報が必要なら、その設計はシークレット不足です。一方、通常のバックアップにすべての認証情報が平文で含まれているなら、シークレット過多です。
ZimaSpaceの最小権限の境界が最終確認になります。各サービス、バックアップジョブ、管理者、復旧プロセスには、それぞれの役割に必要なシークレットだけを与えてください。予期せずその境界を越えたものは、すべてローテーションしてください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinでは共有アカウントを1つ使うべきか、それとも家庭内で別々のアカウントを使うべきか？
必要な本人確認、アクセス、ペアレンタルコントロール、復旧の境界に応じて、Jellyfinの家庭用アカウントを選択してください。
作業完了後もJellyfinのメモリ使用量が高いままなのはなぜですか？
Jellyfinプロセスの増加とLinuxキャッシュを切り分け、メモリ使用量が増え続けるか、実際にメモリ圧迫が発生した場合にのみ調査してください。
Jellyfinのストレージ構成が復旧リスクになりつつある兆候
Jellyfinのストレージの役割を監査し、稼働中の状態をバックアップや再構築可能なデータから分離したうえで、復元によってその構成を検証する。
