課題とスコープ
これはプラットフォームセキュリティエンジニア向けのシステムデザインに関する質問です。Kubernetes v1.36では、アルファ機能としてマニフェストベースのアドミッション制御が導入されています。ポリシーはリクエストを処理する前にAPIサーバーのローカルディレクトリからロードされるため、この設計はetcdが利用可能になる前に機能する必要があり、ファイルベースの復旧パスを含める必要があります。
面接官が評価するポイント
- ブートストラップポリシーとAPI管理ポリシーの分離。
- アトミックな検証、ロールバック、およびフェイルファストな起動動作。
- 特権的な削除からのポリシーおよびWebhook構成の保護。
- APIサーバーインスタンス間での構成配布とドリフト検出。
- オペレーター向けのエスケープハッチ、監査性、および障害モードのテスト。
どのリソースが保護されるか？
ベースラインで保護する対象がValidatingAdmissionPolicyオブジェクトのみなのか、それともバインディング、Webhook、Mutating構成も含まれるのかを明確にします。その回答によってマッチングルールと影響範囲（ブラスト半径）が変わります。
復旧の権限はどこにあるか？
APIが利用できない場合や、ポリシーが自己修復をブロックしている場合、信頼できるパスはAPIサーバーのホストまたはそのイミュータブルな構成パイプラインでなければなりません。そのパスを変更できる権限者と、変更がどのようにレビューされるかを定義します。
稼働するAPIサーバーの台数はいくつか？
各インスタンスは自身のローカルファイルを読み取ります。フリート構成では、コンテンツアドレス指定されたアーティファクト、ロールアウトの順序制御、構成ハッシュのメトリクスが必要です。単一サーバーであればシンプルなローカルウォッチャーを使用できますが、それでもアトミックな置き換えが必要です。
30秒の回答フレームワーク
「API管理ポリシーを有効にする前に、レビュー済みの小規模なマニフェストポリシーをインストールします。これは保護対象としてマークされたリソースに対する更新または削除を拒否し、その名前には予約された.static.k8s.ioサフィックスを使用します。すべてのAPIサーバーは同じバージョン管理されたディレクトリを受け取り、自身の構成ハッシュを公開します。ファイル変更はアトミックに検証およびスワップされます。無効な更新では直前の正常なバージョンが保持され、無効な起動時はフェイルファストします。オペレーターはブロックされたAPI経由ではなく、常にホストの構成パスを通じて復旧を行います。」
ステップバイステップの設計
トラストバウンダリのブートストラップ
すべてのAPIサーバーでManifestBasedAdmissionControlConfigを有効にし、既存のアドミッション構成ファイルを通じてstaticManifestsDirを構成します。マニフェストは、整合性が検証された読み取り専用のアーティファクトに保存します。メトリクスや監査レコードでファイルベースのオブジェクトとAPIオブジェクトを区別できるように、すべての静的オブジェクト名が.static.k8s.ioで終わることを必須とします。
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
configuration:
staticManifestsDir: /etc/kubernetes/admission/static保護ルールの記述
ブートストラップポリシーは、アドミッションポリシー、バインディング、Webhook構成に対するUPDATEおよびDELETE操作にマッチします。古いオブジェクトにplatform.example.com/protected=trueなどの保護ラベルが付与されている場合にのみ変更を拒否します。これにより、ベースラインを保護しながら、通常の実験的運用を可能に保ちます。
更新のトランザクション化
APIサーバーは変更されたファイルセットを検証し、アトミックにスワップします。実行時に検証が失敗した場合は、以前の正常な構成を維持し、エラーをログに記録します。起動時は、マニフェストが無効な場合にリクエストの処理を開始する前に失敗させます。ベースラインがないままサイレントに起動すると、この機能が解決しようとしているブートストラップギャップがまさに発生してしまいます。
マルチサーバーフリートの運用
すべてのAPIサーバーに同じコンテンツアドレス指定されたバンドルをレンダリングし、1インスタンスずつロールアウトします。構成ハッシュラベルとアドミッション判定メトリクスを比較します。ハッシュの不一致は無害なバージョン差ではなくドリフトであるため、ポリシーのセマンティクスを変更する前にロールアウトを停止し、既知の正常なバンドルを復元します。
エスケープハッチの確保
静的ポリシーは、Service、paramKind、または他のAPIオブジェクトに依存してはなりません。これらの参照はクラスタの状態が存在する前には利用できません。ファイルを置き換えるための監査可能なホストレベルのパスを維持し、不正な形式のポリシーや過度に広範なポリシーをAPI呼び出しなしで元に戻せることをテストします。
高品質な模範解答
「静的ディレクトリを信頼の起点（Root of Trust）として扱い、署名付きのバージョン管理されたバンドルをすべてのAPIサーバーに配布し、静的ポリシーを使用してラベル付けされたアドミッションリソースの変更を拒否します。.static.k8s.ioで終わる名前により、出所を可視化します。ランタイム時の編集はアトミックに検証およびスワップされ、起動時は無効なバンドルを拒否します。各サーバーは構成ハッシュをエクスポートするため、ドリフト発生時にはロールアウトが停止します。復旧はAPIリクエストではなく監査されたホストの変更によって行われ、カナリアテストによってブートストラップ、削除試行、不正な更新、サーバーの再起動、混在バンドルのケースを網羅します。」
よくある間違い
- ポリシーを別のAPIポリシーで保護する → APIは自身の構成を保護できないため、静的ファイルに保護をアンカーする必要があります。
- 1つの不正な編集でアクティブなセット全体が置き換わってしまう → 構文エラーによってすべての保護が失われる恐れがあるため、セット全体を検証し、直前の正常なバージョンを維持します。
- 無効なマニフェストのまま起動する → 意図したベースラインなしでサーバーが稼働してしまうため、リクエストを処理する前にフェイルファストさせます。
- APIサーバー間でファイルが共有されていると想定する → 1つのインスタンスが異なるポリシーを適用してしまう可能性があるため、バンドルを配布してハッシュを比較します。
- オペレーターのエスケープハッチをすべて排除してしまう → ポリシーのバグがそのまま障害につながるため、特権を持つ監査可能なホスト復旧パスを維持します。
採点基準とセルフチェック
ブートストラップの安全性、ポリシーのマッチング、アトミックな更新、フリートの一貫性、復旧、およびテストを評価します。優れた回答では、循環的なアドミッションに陥ることなく静的構成がAPI管理リソースを保護できる理由と、設計においてオペレーター向けに非API復旧チャネルが意図的に用意されている箇所が明確に説明されています。
フォローアップと発展課題
ロールアウト中にAPIサーバーが再起動した場合はどうなるか？
古いバンドルを引き続き利用可能にしておき、静的アドミッションのロード成功をReadinessの条件とし、報告されたハッシュを比較した上でサーバーをトラフィックに復帰させます。
静的ポリシーからService Webhookを参照できるか？
いいえ。この機能はクラスタの状態が存在する前に自己完結している必要があります。URL専用のWebhookまたはAPIリソースへの依存関係がないCELポリシーを使用し、可用性のトレードオフをドキュメント化してください。
自身の削除をブロックするポリシーはどのようにテストするか？
保護されたテストオブジェクトを作成し、API経由で更新および削除を試みて、拒否と監査レコードを確認します。その後、復旧パスを通じて静的バンドルを置き換え、オブジェクトが管理可能になることを確認します。
ロールアウトにおける不変条件（Invariant）は何か？
サービスを提供中のすべてのAPIサーバーが承認された同一のバンドルハッシュを適用している必要があり、APIが構成変更を拒否した場合でも、少なくとも1つの監査可能な復旧パスが利用可能であり続けなければなりません。