プロンプトとスコープ
SELinuxをenforcingモードで実行しているLinuxノード上のマルチテナントKubernetesクラスターを運用しています。プラットフォームはCSIボリュームを使用しており、一部のワークロードはボリュームを共有しています。チームはv1.36へのアップグレードを計画しています。すべてのノードでSELinuxが有効になっていると仮定せずに、互換性チェック、カナリアロールアウト、オブザーバビリティ、およびロールバックを設計してください。
面接官がテストしていること
面接官は、SELinuxノードと通常のノードを区別できるか、マウントコンテキストと再帰的リラベリングの違いを説明できるか、特権Podと非特権Podがボリュームを共有する際のリスクを特定できるかを評価しようとしています。優れた回答には、CSIドライバー、PodのsecurityContext、起動レイテンシ、データアクセス、アドミッション境界、バージョン管理されたロールバックについての説明も含まれます。
最初に明確にすべき質問
- どのノードがenforcingであり、サポートスコープに含まれるCSIドライバーとファイルシステムはどれか？
- 共有ストレージはビジネス上の必須要件か、それともボリュームを分割したり明示的にデータを交換したりできるか？
- 移行では起動レイテンシ、テナントの分離、ワークロードの継続性、または明示的なトレードオフのどれを最適化しているか？
- デプロイされたバージョンで明示的なラベリングポリシーが許可されているか、またロールバックウィンドウと証拠保持の要件はどのようなものか？
30秒の回答
「まず、ノードのSELinuxモード、CSIドライバー、ボリュームタイプ、および共有関係のインベントリを作成します。v1.36の改善により、サポートされているボリュームにはマウントコンテキストが使用され、再帰的リラベリングのコストが削減されますが、共有ボリュームのアクセス結果が変わる可能性があります。展開を拡大する前に、分離されたノードプールで同等のワークロードを実行し、マウント、ラベル、読み取り/書き込み、起動レイテンシ、拒否ログを確認します。ガードレールに引っかかった場合は、新規ワークロードを停止し、実行中のPodと証拠を保持した上で、デプロイされたバージョンでサポートされているポリシーを使用してロールバックします。」
ステップごとのソリューション
1. 影響インベントリの構築
各ノードのカーネルとSELinuxの状態、enforcingまたはpermissiveモード、Kubernetesバージョン、CSIドライバーのバージョン、ボリュームタイプを記録します。各PodのseLinuxOptions、ID、特権レベル、マウントパス、共有関係をエクスポートします。SELinuxのないノードを同じ挙動の結論に含めてはなりません。
2. 挙動の変化の説明
Kubernetesの変更により、SELinuxのボリュームラベリング改善がv1.36で安定版になります。サポートされているボリュームでは、システムはすべてのファイルを再帰的にリラベルする代わりにマウントコンテキストを使用できます。これにより通常、大容量ボリュームの起動処理が削減されますが、異なるセキュリティドメインが共有ボリュームにアクセスする場合、使用前にリラベルされるという前提が崩れる可能性があります。マウントに成功したからといって、アプリケーションが読み書きできることの証明にはなりません。
3. ドライバーとポリシー境界の確認
すべてのCSIドライバーについて、マウントコンテキストのサポート、ファイルシステムの挙動、マウントオプションの制限を検証します。seLinuxChangePolicy、関連するフィーチャーゲート、およびデフォルト値については、デプロイされたバージョンのドキュメントを確認します。検証なしに古いリリースからフィールドをコピーしたり切り替えたりしないでください。アドミッションポリシーは、不要な特権を制限し、共有ボリュームのセキュリティドメインを定義し、変更を監査する必要があります。
4. 再現可能な比較の実行
同じイメージ、UID/GID、securityContext、ボリュームデータを持つテストPodを準備します。単一のPod、同一ドメイン内での共有、特権/非特権での共有、空のボリューム、多数のファイルを含むボリュームを対象とします。マウントコンテキスト、ファイルラベル、読み取り/書き込み、再起動時の復元、拡張、CSI再接続を検証します。Pod作成からReadyまでの各間隔を測定します。
5. カナリアガードレールの追加
専用のノードプールとCSI StorageClassの少数のセットを作成し、再試行可能なジョブから開始します。カナリア実行中に、未検証のセキュリティドメインの組み合わせに同じ共有ボリュームを割り当てないでください。拒否ログ、マウント失敗、アプリケーションの権限エラー、起動レイテンシ、再起動成功に対する閾値を設定します。ガードレールが作動した場合は展開を停止し、SELinuxや特権を拡大して問題を隠さないでください。
6. 共有ボリュームのリスクの処理
特権Podと非特権Podでボリュームが共有されている場合は、続行する前にまずボリュームを分割するかセキュリティドメインを統一します。共有が避けられない場合は、誰がラベリングを所有し、いつボリュームがマウントされ、どのように再要求されるかを定義し、実際のアクセスマトリックスを検証します。ラベリングの問題をデータ損失と誤認しないよう、アプリケーションの復旧が証明された後にのみ古いボリュームを削除します。
7. ロールバック証拠の保持
ロールバックは、実行中のジョブとイベントを保持しながら、カナリアプールへの新規Podの進入を停止することから始まります。次に、デプロイされたバージョンで明示的にサポートされている再帰ポリシーまたは古いノードプールを選択します。フィーチャーゲート設定、ノードラベル、CSI設定、Podマニフェスト、SELinux AVC拒否ログを保持します。ロールバック後に同じ比較を再実行します。デプロイコマンドの成功だけでは復旧の証明になりません。
模範解答
移行はインベントリ、比較、カナリア、ロールバックとして構成します。enforcingモードでSELinuxが使用可能なLinuxノードのみが対象であり、デプロイされたKubernetesバージョンに対してCSIドライバーのサポートを確認する必要があります。v1.36ではサポート対象ボリュームにマウントコンテキストが使用されるため、再帰的リラベリングは削減されますが、共有ボリュームや異なるセキュリティドメインに対する重点的なテストが必要です。テストでは、空のボリュームと大容量ボリューム、単一Pod、同一ドメイン共有、特権/非特権共有を網羅し、ラベル、アクセス、拒否ログ、起動レイテンシ、再起動復元を比較します。カナリアプールは再試行可能な作業のみを受け入れます。閾値を超えた場合は展開を停止し、証拠を保持し、新規作業をドキュメント化されたサポート対象パスに戻します。
よくある間違い
- すべてのノードをSELinuxノードとして扱う → 影響範囲が誤る → ノードモードとenforcing状態で分割する。
- マウント成功のみをテストする → ランタイムアクセスが依然として拒否される → 実際のID、ラベル、読み取り、書き込み、再起動をテストする。
- 直ちに特権を拡大する → セキュリティ境界が広がる → セキュリティドメイン、共有関係、またはドライバー設定を修正する。
- CSIの違いを無視する → カナリアで1つのボリュームクラスが失敗する → ドライバー、ファイルシステム、ボリュームタイプのマトリックスを作成する。
- ロールバック中にすべてのPodを削除する → 証拠が失われ、ジョブが停止する → 新しいトラフィックを凍結し、状態とログを保持する。
フォローアップの質問と回答
permissiveモードでも同様の移行が必要ですか？
permissiveモードは通常拒否を強制することなく拒否を記録するため、依然としてインベントリとテストを行う価値があります。enforcingの挙動を表すものではないため、リリースゲートはenforcingノードで再現する必要があります。
ラベリングの問題とCSIの問題をどのように切り分けますか？
ノード、イメージ、セキュリティコンテキストを一定に保ちながら、ボリュームタイプまたはドライバーを入れ替えます。マウントイベント、カーネル拒否、ファイルラベル、CSIログを比較します。複数のドライバー間で再現する場合にのみ、問題をセキュリティコンテキストパスに帰属させます。
起動の高速化だけで成功を証明できますか？
いいえ。パフォーマンスはシグナルの1つにすぎません。異なるドメインのアクセスマトリックス、再起動復旧、拡張、再接続の挙動、監査証拠もリリースゲートを満たす必要があります。
共有ボリュームで単一のセキュリティドメインを使用できない場合はどうしますか？
ボリュームを分割するか、明示的なデータ交換パスを使用することを推奨します。共有が避けられない場合、プラットフォームがセキュリティドメインとライフサイクルの決定を所有し、許可されたPodの組み合わせを強制してリグレッションテストを行う必要があります。