プロンプトと適用コンテキスト
ある Kubernetes クラスターに、コンテナ内で UID 0 として実行され続けているレガシーイメージが含まれています。セキュリティチームはコンテナエスケープによるホストへの影響を軽減するためにユーザー名前空間（user namespaces）の導入を求めていますが、ビジネス側はボリュームの所有権、hostPath、監視エージェント、特権ケーパビリティ、古いノードへの影響を懸念しています。移行、検証、カナリア、可観測性、ロールバックの計画を設計してください。
これはシステムデザインの設問です。単に hostUsers: false と記述するのではなく、分離モデルを識別子、ストレージ、スケジューリング、ポリシー、運用へマッピングできるかが評価シグナルとなります。
面接官が評価するポイント
- ケーパビリティのスコープを含め、コンテナ root とホスト UID の違いを説明できるか。
- ボリューム、ホスト名前空間、CRI/OCI ランタイム、Pod Security にわたる境界を見極められるか。
- 既存のワークロードを壊すことなく、互換性チェックと段階的移行を設計できるか。
- セキュリティ上のメリット、パフォーマンスコスト、SLO、メトリクス、ロールバック条件を定義できるか。
- 移行後のアプリケーション、デバッグ、監視、バックアップにおける反例に対処できるか。
Kubernetes は v1.36 でユーザー名前空間を安定版とし、デフォルトで有効化されているとドキュメントに記載しています。Pod は spec.hostUsers: false を使ってオプトインします。Amazon の SDE II 向け資料では、信頼性、効率性、最適化、スケーラビリティを通じてシステムデザインを評価します。この設問では、セキュリティ上のメリットと運用リスクを合わせて定量化する要件が加わります。
確認のための質問
- クラスターは Linux のみで構成されており、kubelet、CRI、OCI ランタイム、カーネルバージョンは要件を満たしていますか？
- ワークロードは hostNetwork、hostPID、hostIPC、hostPath、デバイス、特権コンテナ、またはホスト UID を必要とする監視エージェントを使用していますか？
- どのボリュームが Pod 間で共有されており、既存ファイルの UID/GID はマッピング可能な範囲内に収まっていますか？
- アプリケーションは本当にホストの root を必要としていますか、それともコンテナ内での root セマンティクスのみで足りますか？
- 目的はエスケープの封じ込め、Pod Security への準拠、あるいはコンテナローカルなネットワーク管理など特定の名前空間化されたケーパビリティの利用ですか？
- ロールバック用に hostUsers=true のテンプレートを保持したまま、名前空間、ノードプール、またはワークロード単位でカナリアリリースを実行できますか？
30秒で答える回答フレームワーク
Linux、カーネル、CRI/OCI ランタイム、ホスト名前空間、ボリューム、特権ケーパビリティに関する適合性マトリクスを構築します。適合する Pod にのみ hostUsers: false を設定します。ホスト側からはマッピングされた非特権 UID として認識されつつ、アプリケーションの UID セマンティクスが安定して維持されていることを検証します。ファイルアクセス、監視、ネットワーク、デバッグをテストした上で、ワークロード単位でカナリア展開します。起動レイテンシ、権限エラー、OOM、エスケープ制御、ビジネス SLO を監視し、閾値を超えた場合は旧テンプレートへ切り戻します。
ステップバイステップの詳細回答
1. 分離モデルの説明
ユーザー名前空間は、コンテナ内のユーザーを異なるホスト UID および GID にマッピングします。コンテナ内の root はその名前空間内で必要な操作を実行できますが、そのケーパビリティはその内部でのみ有効であり、ホストの root 権限を付与するものではありません。Kubernetes は hostUsers: false によって Pod をオプトインさせ、ノード上で重複しないホストマッピングを割り当てます。
これはカーネルのアイデンティティ境界を変更するものであり、完全なサンドボックスではありません。seccomp、AppArmor または SELinux、ネットワークポリシー、読み取り専用ファイルシステム、最小権限の原則、パッチ適用済みノードを引き続き併用してください。ユーザー名前空間は多層防御の1つの制御策であり、あらゆるエスケープ経路に対する万能の解決策ではありません。
2. ランタイムおよびノードの適合性チェック
対象となるすべてのノードで、kubelet、CRI、OCI ランタイムにおけるユーザー名前空間のサポート状況を確認します。Kubernetes のドキュメントには、containerd 2.0、CRI-O 1.25、runc 1.2、crun 1.9 などのサポートが記載されていますが、デプロイ時にはカーネル、idmapped マウント、ディストリビューション設定の検証が依然として必要です。
アドミッションポリシーによって、適合しないノードやケーパビリティの組み合わせを拒否できます。CI で最終的な Pod をレンダリングし、hostUsers、セキュリティコンテキスト、ホスト名前空間、ボリュームタイプをチェックします。ロールアウト前に、プローブ Pod を使って作成、マウント、再起動、ノードの再スケジューリングを検証します。
3. ボリュームと UID/GID の評価
Pod の runAsUser、runAsGroup、fsGroup は、依然としてコンテナ内のユーザーを表します。ボリュームのパーミッションセマンティクスは以前と同様に使用可能であるべきなため、通常はユーザー名前空間を有効にしたという理由だけでアプリケーション全体の所有権書き換えを行う必要はありません。
マッピングされた UID/GID 範囲外のファイルはオーバーフロー ID として表示され、書き込み不可になる可能性があります。移行前に、所有者、初期化スクリプト、共有ボリューム、バックアップ/リストアツールをスキャンしてください。そのワークロードでユーザー名前空間を有効にする前に、イメージやデータを修正します。
4. 禁止された組み合わせとポリシーの処理
ユーザー名前空間が有効な場合、Pod は hostNetwork、hostPID、hostIPC などの特定のホスト名前空間を使用できません。ホストデバイス、特権モード、特別な proc マウントを必要とするワークロードには、個別のレビューが必要です。Pod Security Standards では選択されたチェックが制御された形で緩和される場合がありますが、これは他のすべてのポリシーを撤廃してよいという許可ではありません。
ホスト名前空間に依存するワークロードは延期（保留）としてマークし、例外承認、代替補償統制、有効期限を記録します。アドミッションを通過させるためだけにフィールドを自動削除しないでください。機能的な障害が見えないセキュリティ低下に変わってしまいます。
5. パフォーマンス、SLO、可観測性の設計
Pod の起動およびボリュームマウントのレイテンシ、ノードの CPU とメモリ、コンテナ内の権限エラー、監視の喪失、バックアップ/リストアの成功率、再起動を追跡します。idmapped マウントにより大容量ボリュームでの再帰的な chown を回避できますが、理論上の主張に依存せず、実際のカーネル、ランタイム、ファイルシステムで測定してください。
ログやメトリクスには、移行バージョン、ノードプール、イメージ、ボリュームタイプのタグを付与します。セキュリティシグナルには、拒否されたエスケープテスト、失敗した特権操作、Pod Security 違反が含まれ、ビジネスシグナルにはリクエストエラー、レイテンシ、データ整合性が含まれます。
6. 段階的移行とロールバック
ホスト名前空間を使用せずシンプルなボリュームを持つステートレスなワークロードから開始し、その後ステートフルなサービスへと拡大します。バッチごとに hostUsers=true テンプレートのハッシュを保持します。権限エラー、起動時間の悪化、ビジネスエラー率の上昇、ボリュームの読み書き失敗、ノードからのエビクション（Eviction）が発生した場合は自動停止します。
ロールバックでは単一のフィールド以上の変更が伴います。ボリュームマウント、runAs ユーザー、監視エージェント、アドミッションの出力が元の状態に戻ることを確認してください。障害の原因特定を可能にしておくため、同じ時間枠でランタイム、カーネル、イメージを同時にアップグレードすることは避けてください。
7. セキュリティ上のメリットと残存リスクの明示
ユーザー名前空間は、コンテナ root のエスケープによるホストへの影響を軽減し、コンテナローカルな管理を必要とするワークロードに対してより狭いドメインを提供します。しかし、アプリケーションのシークレット、コンテナ間のロジック攻撃、不適切なネットワークポリシー、あるいはすでに侵害された共有サービスを保護することはできません。
セキュリティレビューでは、残存する hostPath、デバイス、ケーパビリティ、カーネルインターフェース、サービスアカウントを一覧化し、seccomp、SELinux、ノード分離、脆弱性パッチ適用を多層防御として統合する必要があります。
質の高い回答例
適合性マトリクスを構築します。対象ノードは Linux であり、kubelet、CRI/OCI ランタイム、カーネル、ファイルシステムにおいてユーザー名前空間の要件を満たしている必要があります。hostNetwork、hostPID、hostIPC、特権デバイス、またはホスト UID 前提を使用している Pod は除外します。適合するテンプレートに hostUsers: false を設定し、ホスト側からは非特権マッピングとして見えつつ、コンテナの UID/GID セマンティクスが正しく維持されていることをテストで確認します。
ロールアウト前に、オーバーフロー ID の挙動を含め、ボリュームの所有者、初期化スクリプト、共有ボリューム、バックアップ/リストア経路をスキャンします。プローブ Pod を使って作成、マウント、再起動、再スケジューリングを検証します。カナリアでは、起動・マウントレイテンシ、権限エラー、ビジネス SLO、エビクション、監視、バックアップのシグナルを測定します。即時ロールバック用に旧テンプレートのハッシュを利用可能な状態にしておきます。
ユーザー名前空間を多層防御の1つのレイヤーとして扱い、seccomp、SELinux/AppArmor、ネットワークポリシー、最小権限、ノードのパッチ適用を維持します。セキュリティ上のメリット、パフォーマンスコスト、延期されたワークロードを移行チェックリストに記載します。単一のフィールドを設定するだけでは移行とは言えません。
よくある間違い
- Linux、ランタイム、カーネル、ボリュームの条件を確認せずに
hostUsers: falseのみを記述すること。 - コンテナの root が単なる一般ユーザーになると説明し、2つの UID の意味を無視すること。
- ユーザー名前空間を、あらゆるエスケープ、特権、ネットワークリスクに対する自動的な万能薬として扱うこと。
- hostNetwork、hostPID、hostIPC、hostPath、デバイス、proc マウントの制限を見落とすこと。
- すべてのボリュームに対して再帰的に chown を実行したり、オーバーフロー UID/GID ファイルのスキャンを怠ったりすること。
- ランタイム、カーネル、イメージを同時にアップグレードし、障害原因の特定を不可能にすること。
- 旧テンプレート、自動停止条件、または検証可能なロールバック手順を用意していないこと。
フォローアップの質問と回答
ユーザー名前空間が安定版となったのはどの Kubernetes バージョンですか？
公式ドキュメントでは、Kubernetes v1.36 で機能が安定版（stable）となりデフォルトで有効化されています。Pod 側では引き続き spec.hostUsers: false によるオプトインが必要です。ロールアウト前に実際のクラスターとノードのバージョンを確認してください。
コンテナ root は引き続きケーパビリティを使用できますか？
そのユーザー名前空間内で有効なケーパビリティは使用できますが、それらのケーパビリティが自動的にホストの特権になることはありません。最小権限、seccomp、LSM 制御を適用してください。
既存の PVC の権限はすべて壊れますか？
通常、コンテナの UID/GID セマンティクスは安定して維持されるため、全面的な所有権の書き換えは不要です。マッピング範囲外のファイルはオーバーフロー ID になる可能性があるため、スキャンと修正が必要です。
なぜ hostNetwork と組み合わせることができないのですか？
ユーザー名前空間はユーザーとリソースの境界分離に依存しており、一部のホスト名前空間との組み合わせはその分離を損なうため、Kubernetes では許可されていません。ホストネットワークを使用するワークロードは、代替補償統制を備えた明示的な例外として管理してください。
リスクが軽減されたことをどのように証明しますか？
エスケープ分離および特権操作のテストを実行し、ホスト UID、ケーパビリティ、アクセススコープを観察するとともに、ビジネスエラー、起動レイテンシ、ボリュームの整合性を比較します。Pod の作成成功だけでは証明になりません。
どのワークロードの移行を保留すべきですか？
ホスト名前空間、特別なデバイス、特権カーネルインターフェースを必要とするワークロードや、修復不可能なボリューム UID/GID レイアウトを持つワークロードは延期します。その理由、代替補償統制、再評価日を記録してください。