問題と背景
Kubernetes ValidatingAdmissionPolicy は、API リクエストに対して CEL 式を評価します。ポリシー定義は、リソースを選択して適用アクションを定義するバインディングとペアになります。これによりクラスタネイティブな検証パスが提供されますが、スコープの設定ミスやポリシーの利用不能によって正当な復旧オペレーションが拒否される可能性があります。
本番環境のネームスペースにはラベルが付与されており、イメージの出所（provenance）がアドミッションフィールドとして利用可能で、プラットフォームエンジニアがポリシーを管理していると仮定します。この設計では、厳格な安全ルールと警告を区別し、ドライランをサポートし、監査された緊急用パスを維持する必要があります。
面接官が評価するポイント
面接官は、ポリシー定義とバインディングの分離、明示的な障害時の挙動、絞り込まれたリソースマッチング、およびテスト可能な例外モデルをチェックします。優れた回答では、CEL の型チェック、バージョン管理されたロールアウト、監査メトリクス、ポリシーエンジンや参照データが利用できない場合に何が起きるかについて議論されます。
一般的な回答は、不正な YAML を拒否する単一の式を記述するだけにとどまります。優れた回答は、スコープ、アクションレベル、互換性、可観測性、ロールバックについて説明します。
最初に明確にすべき質問
- どの API グループ、バージョン、ネームスペース、操作が対象ですか？
- ルールはイメージの同一性、ダイジェストの固定、ホストアクセス、またはそれらすべてに関するものですか？
- パイロット運用中、違反は deny（拒否）、warn（警告）、それとも audit（監査）のみとすべきですか？
- どのコントローラーやシステムネームスペースに例外が必要で、誰がそれを承認しますか？
- ポリシーがインシデントの修正をブロックした場合の復旧パスは何ですか？
ルールが CEL から確実にアクセスできない外部状態に依存している場合は、ポリシーをローカルにとどめ、より高度なチェックには別のコントローラーを使用します。例外が広範すぎる場合、ポリシーは誤った安心感を与える可能性があります。
30秒での回答
「小さく型付けされた CEL ルールを定義し、それらを本番ワークロードと関連する操作にのみバインドします。監査または警告モードから開始し、所有者ごとの違反を測定した上で、一度に1つのルールを適用します。例外は限定的かつ監査対象とし、テスト済みの緊急パスを用意します。アドミッションレイテンシ、拒否率、復旧成功率を監視し、ポリシーの挙動が安全でない場合はバインディングをロールバックします。」
ステップバイステップの設計
- 不変条件（Invariant）の定義。 承認済みイメージレジストリ、ダイジェストの要件、ホスト権限に対して個別のルールを作成します。テストや説明が困難な単一の式は避けます。
- CEL の型チェックとテスト。 欠落フィールド、リスト、更新、削除操作などを含め、対象リソースのスキーマに対して式を検証します。ポリシーレビューのワークフローにフィクスチャを保持します。
- バインディングによるスコープ設定。 保護が必要な本番ネームスペース、ワークロードの種類、操作のみをマッチさせます。バインディングを分離することで、チームごとにルールを個別に適用できます。
- 強制レベル（Enforcement）の選択。 監査または警告から開始し、所有者が違反を修正した後に deny に昇格させ、変更履歴にアクションを記録します。
- 例外の設計。 指定されたシステム ID またはネームスペースのみを免除し、有効期限または承認記録を必須とし、例外が使用されたときにアラートを発報します。
- 安全なロールバック。 ポリシー定義をバージョン管理し、履歴を削除するのではなくバインディングを無効化し、緊急 Deployment が文書化されたパスに基づいて続行できることを確認します。
代替案としては、外部データ用の検証 Webhook や、正規化のためのミューテーション＋検証があります。API サーバーの近くで強制する必要がある決定論的かつローカルな不変条件には、組み込みポリシーを使用します。
回答例
「本番 Deployment 向けに、レジストリの許可リスト、ダイジェスト必須、hostNetwork 禁止の3つのポリシーを作成します。各バインディングは、ラベル付けされた本番ネームスペースのみを選択します。パイロットは監査モードで1週間実行され、所有者は違反レポートを受け取り、deny を有効にする前に誤検知を修正します。プラットフォームおよびブレークグラス（緊急用）ID のみが例外となり、有効期限と監査イベントが設定されます。アドミッションレイテンシと拒否された復旧変更をアラート対象とし、インシデントによって安全でないルールが判明した場合はバインディングを無効化してロールバックします。」
よくある間違い
- 間違い: すべてのネームスペースと操作をマッチさせる → 失敗する理由: システムコントローラーと復旧パスがブロックされる → 修正方法: バインディングのスコープを狭く設定する。
- 間違い: 警告を強制措置として扱う → 失敗する理由: ユーザーが安全性は保証されていると思い込む → 修正方法: アクションレベルと昇格基準を周知する。
- 間違い: 欠落フィールドに対して型なしの CEL を使用する → 失敗する理由: アップデートや古い API バージョンで挙動が異なる → 修正方法: 存在しないフィールドのケースを型チェックしてテストする。
- 間違い: 例外を恒久的なものにする → 失敗する理由: 例外的なバイパスが事実上のポリシーになってしまう → 修正方法: 有効期限、所有者、監査を必須にする。
追加の質問と回答
ポリシー式に構文エラーがある場合はどうなりますか？
Kubernetes はポリシー定義を検証し、無効な式を受け入れるのではなくエラーを報告します。それでも、レビュー用フィクスチャで実行し、挙動が確認されるまでバインディングを監査モードにしておく必要があります。
外部の脆弱性データベースを必要とするルールはどのように処理しますか？
CEL が任意の外部状態を取得できるかのように扱わないでください。鮮度、タイムアウト、障害セマンティクスを管理するコントローラーまたは Webhook を使用し、ローカルの不変条件は組み込みポリシーに保持します。
deny ルールが修正作業をブロックした際、オンコールエンジニアはどのように復旧できますか？
有効期限付きで監査される限定的なブレークグラス ID またはネームスペースを提供し、承認を文書化し、使用時にアラートを発報します。強制適用前にそのパスをテストしてください。
どのような場合にポリシーを削除しますか？
誤検知が多い状態が続く場合、アドミッションレイテンシが API サーバーを脅かす場合、または不変条件がより強力なコントロールに移行した場合は、バインディングを削除または無効化します。その決定のために履歴とメトリクスを保存しておきます。