プロンプトと対象範囲
マルチテナントクラスタにおいて、APIサーバーのメモリ消費、ロギングコスト、およびSecretの漏洩を抑制しながら、「誰が」「いつ」「どこから」「何を」変更したかを特定できるようにする必要があります。監査ポリシー、ファイルまたはWebhookバックエンド、サンプリングとアラート、障害処理、およびフォレンジック検証を設計してください。
面接官がテストしていること
- ルールの順序付けと、
None、Metadata、Request、RequestResponseの違いの理解。 RequestReceived、ResponseStarted、ResponseCompleteの各ステージの区別。- 長時間実行されるリクエスト、機密性の高いボディ、バックエンドのブロック、およびログの完全性の処理。
- 監査の目標をアラート、保持期間、アクセス制御、および訓練（ドリル）に結びつける能力。
明確化のための質問
- どのアカウント、動詞、テナント、および高リスクリソースを監査する必要がありますか？
- どのボディにSecret、トークン、または個人データが含まれており、それらをどのくらいの期間保持する必要がありますか？
- バックエンドはファイル、Webhook、またはその両方のどれにすべきですか？また、許容されるデータ損失とレイテンシのウィンドウはどれくらいですか？
- 改ざん検知の証跡、クロスリージョンレプリケーション、および未加工ログへのアクセス制限は必要ですか？
30秒での回答
調査に必要な要件をフィールドや高リスクAPIへマッピングし、ルールを具体的なものから包括的なものへと順序付けます。通常のトラフィックにはMetadataを使用し、選択された変更にはRequestを、Secretの値が通常のログに入らないようにRequestResponseは控えめに使用します。理由が明確な場合にのみ初期ステージを省略します。ファイルまたはTLS Webhookバックエンドを、バッファリング、レート制限、暗号化、整合性チェック、アクセス監査、および損失アラートによって保護します。バックエンド障害の訓練を実施して、選択したセマンティクスを検証します。
ステップバイステップの設計
1. フォレンジックの要件を定義する
「誰が」「いつ」「どこで」「何を」をフィールドとクエリに変換します。高リスクなオブジェクトには、Secret、RoleBinding、Webhook、ノード、テナントクォータが含まれます。日常的なヘルスチェックで完全なボディが必要になることは滅多にありません。ポリシーはすべての可能なフィールドを収集するのではなく、調査の質問に答えるものである必要があります。
2. 順序付けられたルールを作成する
ルールは具体的なものから包括的なものへと順序付けます。最初に一致したものがレベルを設定します。高リスクな変更にはRequestまたは必要なRequestResponseを使用し、日常的な読み取りにはMetadataを、明示的なノイズにはNoneを使用し、気付かないログの抜け漏れを防ぐために低レベルのフォールバックを設定します。
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- RequestReceived
rules:
- level: Request
resources:
- group: ""
resources: ["secrets"]
- level: Metadata
omitStages: ["RequestReceived"]
resources:
- group: ""
resources: ["pods"]
- level: None
users: ["system:kube-probe"]3. ステージと機密フィールドを制御する
長時間実行されるリクエストはResponseStartedを出力し、その後ResponseCompleteを出力することがあります。ステージの省略によって重複を減らすことができますが、1つのリクエストが生成するイベントが1つだけである必要はありません。Secretや認証情報については、通常のログシステムに生の値を入れるのではなく、メタデータ、ハッシュ、または制御された要約を優先します。
4. バックエンドの選択と保護
ファイルログを確実にローテーション、圧縮、暗号化し、転送します。WebhookにはTLS、認証、キュー、およびバックプレッシャーが必要です。パイプラインをテナントとリスクによって分割し、追記専用（append-only）ストレージを使用し、監査ID、ポリシーバージョン、および受信時刻を付与します。ダウンストリームのコンシューマーがAPIサーバーを同期的にブロックしてはなりません。
5. 障害セマンティクスを定義する
バックエンドが到達不能になった場合、ディスクが一杯になった場合、キューがオーバーフローした場合、またはネットワーク分断が発生した場合の動作（ドロップ、ブロック、または機能低下）を指定します。高リスクな書き込みは、コントロールプレーンへの影響を定量化した後にのみフェイルクローズ（fail-closed）を使用できます。通常のトラフィックには、制限付きバッファリングとアラートを使用できます。損失カウンターと復旧スキャンの範囲を記録します。
6. 継続的な検証と改善
既知のユーザー、ServiceAccount、プロキシ、および長時間実行されるリクエストからイベントを生成します。ルールの一致、ステージ、テナントの帰属、およびマスキング（redaction）を確認します。Webhookの遅延、ディスクフル、ポリシー更新を注入し、アラート、復旧、およびフォレンジッククエリを検証します。イベント量、損失、レイテンシ、コスト、および調査カバレッジを追跡します。
模範的な高品質の回答
調査の質問をフィールドと高リスクリソースにマッピングし、ルールを具体的なものから包括的なものへと順序付けます。日常的なトラフィックにはMetadataを、Secretには制御されたメタデータを、選択された変更にはRequestを割り当て、長時間実行されるステージは明示的にします。バックエンドは、コンシューマーがAPIサーバーをブロックしないようにしつつ、バッファリング、バックプレッシャー、追記専用の完全性、およびアクセス監査を備えた暗号化ファイルまたはTLS Webhookを使用します。障害時の動作には、制限付きバッファリング、損失カウンター、およびアラートを含め、フェイルクローズは影響が定量化された高リスクな書き込み用に限定します。合成イベント、長時間実行リクエスト、および障害訓練によって、ポリシーと復旧経路を検証します。
よくある間違い
- すべてのリクエストを
RequestResponseで記録する → 機密情報の漏洩とコストの急増を招く → リスク別に階層化する。 - ルールの順序を適当にする → 包括的なルールが高リスクイベントを覆い隠してしまう → 具体的なものから一般的なものへと順序付ける。
- ログファイルが存在することだけを確認する → バックエンドの閉塞やデータ損失が見えなくなる → キュー、レイテンシ、損失を監視する。
- ステージを無視する → 長時間実行される調査でタイミングを見失う → ステージと省略理由を定義する。
- WebhookコンシューマーでAPIサーバーを同期的にブロックする → コントロールプレーンの崩壊を招く → バッファ、タイムアウト、バックプレッシャーで分離する。
フォローアップの質問と回答
なぜすべてのSecretリクエストをRequestResponseで記録しないのですか？
ボディに平文のSecretが含まれる可能性があるためです。ほとんどの調査では、プリンシパル、オブジェクト、動詞、および結果が必要です。より深いアクセスには、マスキング、分離された権限、および短期間の制御された保持が必要です。
Webhookが利用できない場合、APIリクエストをブロックすべきですか？
リスクと可用性の目標によります。影響を定量化した後、高リスクな書き込みはフェイルクローズにする一方で、通常のトラフィックには制限付きバッファリングとアラートを使用できます。どちらの選択肢でも、損失と復旧の範囲を可視化する必要があります。
未知のリソースが暗黙のうちに省略されていないことをどのように証明しますか？
低レベルのフォールバックを維持し、ディスカバラインベントリを合成リクエストおよびポリシーバージョンと比較し、手動の検出に頼るのではなく新しいAPIが出現したときにレビューをトリガーします。