はじめに
レポートアプリケーションの設定はすでに読み取り専用ですが、まだ root で動作しています。保守担当者として、実際の文書生成を維持しながら、用意されたアプリケーションユーザーを選びます。
この独立した環境には専用のレポートコンテナとデータがあります。UID と出力の所有者を調べ、前に練習した起動形式を編集し、サービスを再作成してテストします。先に「マウントした設定を保護する」を完了してください。
アプリケーションユーザーを知る
このステップでは、通常のサービス動作を確認し、保守ユーザーとコンテナプロセスのユーザーを区別します。この新しい環境では設定マウントがすでに読み取り専用ですが、生成サービスはまだ root で動作しています。
/home/labex/project/report-desk から始まる Maintenance を使います。このターミナルで管理するのは用意された report-renderer コンテナだけです。必要なら cd /home/labex/project/report-desk で戻ります。sudo docker exec は Docker に対象内でのコマンド実行を依頼します。id は数値のユーザー ID（UID）とグループ ID（GID）を表示します。
sudo docker exec report-renderer id
uid=0(root) gid=0(root) groups=0(root)
このコンテナの UID 0 は root です。アクセス可能なファイルに対し、レポートアプリケーションが必要とする以上の権限を持ちます。コンテナの root は別の VM の管理者ではなく、コンテナはホストのカーネルを共有します。この演習はファイルアクセスを減らすもので、あらゆるコンテナリスクを解決するものではありません。
用意された実行ユーザーは UID/GID 1200:1200 です。数値 ID はイメージに名前付きアカウントを追加しなくても使えます。ホストのディレクトリ所有者は、このユーザーの書き込みを許可する必要があります。ls -ldn はディレクトリ自体（-d）、詳細な権限（-l）、数値 ID（-n）を表示します。
ls -ldn output
drwxr-xr-x と所有者・グループ 1200 1200 を探します。所有者の rwx は読み取り、書き込み、ディレクトリの通過です。他のユーザーの r-x は読み取りと通過のみで、書き込みはできません。このディレクトリは意図したユーザー用に準備されています。
練習済みの POST リクエストで基準文書を生成します。curl -fsS は HTTP エラーを表示し、-X POST は業務処理を依頼します。
curl -fsS -X POST http://localhost:8090/render/baseline
{"saved": "/output/baseline.json", "total": 37, "uid": 0}
レポートは機能しますが、まだ UID 0 が生成しています。Document Desk を開いて保存した文書を確認します。このページには実際の出力ファイルが表示されます。
用意された実行ユーザーを選ぶ
このステップでは、必要なファイルアクセスを保ちながら起動定義の実行ユーザーを変更します。cat でスクリプトを表示します。
cat launch.sh
sudo はホスト管理操作を許可します。別の指定である --user がコンテナアプリケーションのユーザーとグループを決めます。0:0 は UID 0 と GID 0 を意味し、1200:1200 に変えると用意されたユーザーを選べます。ポート 8090、イメージ、両マウントパスを保ちます。設定行はすでに dst=/config,readonly を含み、出力行は書き込み可能のままにします。
ターミナルエディターを開きます。
nano launch.sh
矢印キーで --user 0:0 だけを --user 1200:1200 に置き換えます。Ctrl+O、Enter で保存し、Ctrl+X で終了します。再度ファイルを表示します。
cat launch.sh
ユーザー指定行は次のようになります。
--user 1200:1200 \
定義の変更だけでは稼働中のプロセスは更新されません。再作成の前に、出力ディレクトリの所有者を明示します。chown は数値の所有者とグループを設定します。ホストの保守ユーザーとは異なる ID のため sudo が必要です。対象はディレクトリだけで、既存の全ファイルには及びません。
sudo chown 1200:1200 output
すべてを読み取り専用にしないでください。文書生成には出力の書き込みが必要です。所有者の問題を避けるために全員へ書き込みを許可する必要もありません。既存のディレクトリ権限 755 で、用意された所有者は書き込めます。
再作成して業務結果を維持する
このステップでは新しい実行ユーザーを適用し、正常出力と保護された入力境界をテストします。前と同様に対象コンテナだけを削除し、代わりを起動します。
sudo docker rm -f report-renderer
bash launch.sh
起動に失敗したら nano で launch.sh を修正し、同じ削除コマンドで失敗した対象を削除して、スクリプトを再実行します。ホストのデータは残ります。実際の実行ユーザーを確認します。
sudo docker exec report-renderer id
uid=1200 gid=1200 groups=1200
起動まで少し待って最終文書を生成します。
curl -fsS -X POST http://localhost:8090/render/final
{"saved": "/output/final.json", "total": 37, "uid": 1200}
Permission denied は通常、出力ディレクトリの所有者が違うか、以前の root 実行で final.json が作られたことを意味します。学習済みの sudo chown 1200:1200 output でディレクトリを直します。古い最終ファイルがある場合は、sudo rm output/final.json でその生成文書だけを削除して再要求します。/output の Read-only file system は出力マウントを誤って制限したことを示すので、定義を直してコンテナを再作成します。
生成したファイルを調べます。ls -ln は数値の所有者、cat は内容を表示します。
ls -ln output/final.json
cat output/final.json
所有者 1200、"uid": 1200、合計 37、Report for Harbor Books: 37 orders を探します。Document Desk を更新して新しいファイルを確認します。最後に設定保護が維持されていることを確認します。
sudo docker exec report-renderer touch /config/probe.txt
touch: /config/probe.txt: Read-only file system
この失敗は想定どおりです。非 root ユーザーと読み取り専用マウントは別の問題を扱います。UID の選択はプロセス権限を減らし、マウントモードはコンテナの root からの設定書き込みも防ぎます。生成サービスは実際の仕事を続けられます。
まとめ
ホストの保守権限とアプリケーションの実行ユーザーを区別し、UID/GID 1200 を選択して出力ディレクトリを維持しました。稼働中のプロセスと新しい文書は UID 1200 を使い、設定への書き込みは引き続き拒否されます。
