LinuCレベル3 セキュリティスペシャリスト 堅牢なコンテナ設計 問8
堅牢なコンテナ設計／Rootless モードRootlessモードのDockerで、docker run に --memory 512m --cpus 1 を指定してコンテナを起動したが、指定した上限が効かずに無視された。Rootlessモードでこれらの上限を効かせるための前提条件として適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル3 セキュリティスペシャリストの出題範囲「堅牢なコンテナ設計」に対応。実際の試験問題ではありません）
- A/etc/subuid と /etc/subgid の範囲を65536より広げると、コンテナのメモリやCPUの上限が指定どおりに効くようになる
- Bloginctl enable-linger を実行すると、ユーザーのcgroupが作成されて --memory や --cpus の上限が効くようになる
- Cホストがcgroup v2で動作してsystemdで管理されていることが前提で、使うコントローラがユーザーへ委譲されている必要もある
- DRootlessモードではcgroupを一切操作できないため、上限をかけるにはコンテナを必ずrootのデーモンで動かす必要がある
正解：C
解説
Rootless モードの Docker で --cpus・--memory・--pids-limit などの cgroup による制限を使えるのは、ホストが cgroup v2 で動作し、systemd で管理されている場合に限られます。cgroup v1 のホストでは、これらの指定は想定どおり無視されます。さらに、使用するコントローラがそのユーザーの配下へ委譲されている必要があります。実機では docker info の Cgroup Driver（systemd）と Cgroup Version（2）、および該当ユーザーの cgroup 配下の cgroup.controllers に目的のコントローラ（memory・pids・cpu など）が現れているかで確認します。Docker 公式は memory・pids を典型的に委譲されるコントローラとして挙げ、cpu・cpuset・io などを追加で委譲するには user@.service のドロップインで Delegate= を設定する方法を案内しています。委譲の既定はディストリビューションや systemd のバージョン・設定によって異なるため、OS 名だけで一律に判断せず、実際の委譲状態を確認します。
選択肢ごとの解説
- A誤り。/etc/subuid 等はUID・GIDの対応付けの範囲を決めるもので、リソース制限の可否には関係しません。
- B誤り。enable-linger はログアウト後もユーザーのsystemdを動かし続ける設定で、cgroupによる制限を有効にするものではありません。
- C正しい。cgroup v2とsystemdが前提で、使うコントローラがユーザーへ委譲されている必要もあります。
- D誤り。cgroup v2とsystemdの環境であれば、Rootlessモードでもcgroupによるリソース制限を使えます。