プロンプトとスコープ
プラットフォームチームは、各ネームスペースをKubernetes Pod Security Standardsのrestrictedレベルへと移行する必要があります。ワークロードには本番サービス、共有インフラストラクチャ、一時的なビルドジョブが含まれます。ディスカバリ、是正、例外処理、切り替え、およびロールバックを設計してください。
面接官が評価している点
enforce、audit、およびwarnの異なる副作用の理解。- ネームスペース、ワークロード、例外を1つのガバナンス境界にまとめること。
- すべてを即座に拒否するのではなく、観測結果に基づいて是正を進めること。
- 固定されたポリシーバージョン、監査証跡、緊急ロールバックへの配慮。
明確化のための質問
- どのKubernetesバージョン、テナント境界、リリースツールが使用されていますか？
- ターゲットは
baselineまたはrestrictedのどちらですか？また、ネームスペースごとに異なるレベルを使用できますか？ - 特権、hostPath、またはホストネットワークを必要とするワークロードはどれですか？
- ロールバックとは、単一ポリシーの一時的な引き下げを意味しますか、それとも古いクラスターへのトラフィック切り替えを意味しますか？
30秒での回答
違反を収集し、送信者に行動可能なフィードバックを提供するために、まずはネームスペース単位でauditとwarnから開始します。最初にグローバルのenforceを有効化してはいけません。ポリシーバージョンを固定したうえで、リスクとビジネス上の優先順位に沿って是正を進めます。すべての例外には、所有者、理由、有効期限、および補償コントロールが必要です。小規模なパイロット運用の後、ネームスペースごとにenforceを有効化し、拒否率とリリース成功率を監視します。緊急ロールバックでは、監査証跡を保持したまま、影響を受けたネームスペースのポリシーのみを引き下げます。
ステップバイステップの設計
1. アセットとポリシーのベースラインを確立する
ネームスペース、Podテンプレート、コントローラー、リリースソースのインベントリを作成します。本番環境、共有インフラストラクチャ、開発環境、一時ジョブをグループ化します。各グループのターゲットレベルとバージョンを選択し、例外を記録します。ラベルのないネームスペースは安全なデフォルトではなく、セキュリティ上のギャップです。
2. ブロックする前に観測する
auditを有効化して違反を記録し、クライアントへのフィードバックのために同一レベルでwarnを設定します。ルール、チーム、イメージごとにイベントを集約し、是正キューを作成します。これにより、現在のトラフィックを中断することなくリスクを可視化できます。
metadata:
labels:
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted3. ワークロードを是正する
不要な特権、hostNetwork、hostPID、hostPath、および書き込み可能なルートファイルシステムを削除します。non-root、seccomp、およびcapabilityの制限を追加します。クラスターが拒否する前に特定のフィールドでテンプレートが失敗するよう、CIにポリシーチェックを組み込みます。
4. 例外を管理・統制する
ガバナンスが可能なネームスペースまたは制御されたエントリポイントでのみ例外を許可します。影響、所有者、有効期限、および補償コントロールを記録します。アドミッション免除は永続的な許可リストではありません。更新にはレビューが必要であり、システムネームスペースのすべてを無条件で免除すべきではありません。
5. 段階的にenforceへ切り替える
まずは低リスクのネームスペースに対してenforceを有効化します。拡大する前に、拒否率、リリース失敗率、再起動率、およびテナントからの苦情率を比較します。ポリシーバージョンを固定し、latestの変更による予期せぬ拒否の波が発生しないよう、warnおよびauditでアップグレードをリハーサルします。
6. ロールバックと検証
リリースコントローラーは一時停止して古いテンプレートを復元できなければなりません。コアサービスがブロックされた場合は、auditとイベントを保持したまま、そのネームスペースのみを一時的に引き下げます。新しいPod、Deploymentテンプレート、ローリングアップグレード、Job、例外の期限切れ、およびポリシーバージョンのアップグレードをテストします。
模範的な質の高い回答
まずネームスペースとワークロードのインベントリを作成してポリシーバージョンを固定し、auditと同一レベルのwarnを使用して違反を収集します。CIでセキュリティコンテキストを早期にチェックし、例外には所有者と有効期限を設定します。低リスクのネームスペースを最初にenforceへ移行し、拒否率、リリース成功率、ビジネスエラーが許容範囲内に留まっていることを確認してから対象を広げます。ポリシーのアップグレードはwarn/auditでリハーサルします。サービスがブロックされた場合は、クラスター全体を恒久的に弱体化させるのではなく、該当ネームスペースのポリシーのみをロールバックして監査証跡を維持し、根本原因を修正します。
よくあるミス
- グローバルの
enforceを即座に有効化する → 多くのリリースが一斉に失敗する → audit/warnと段階的アプローチを使用する。 - ラベルのないネームスペースを安全とみなす → ポリシー適用範囲に死角ができる → ラベルを付与してインベントリ化する。
- 恒久的な免除を作成する → リスクが隠蔽されたままになる → 有効期限とレビューを義務付ける。
- クラスター内でのみ違反を発見する → フィードバックが遅すぎる → チェックをCIとテンプレートレビューに移す。
- リハーサルなしで
latestを使用する → バージョン変更が予期せぬ拒否を引き起こす → 固定して事前に観測する。
フォローアップの質問と回答
どちらもブロックしないのに、なぜwarnとauditの両方を有効にするのですか？
warnはリクエストを送信したクライアントに即座のフィードバックを提供し、auditはプラットフォームの測定のために違反を記録します。これらは異なるワークフローをサポートしており、互いを置き換えるものではありません。
例外のスコープはPodとネームスペースのどちらに設定すべきですか？
制御されたエントリポイントを持つ、管理可能なネームスペース境界を優先します。Podごとの許可はコピーや回避が容易です。すべての例外には、依然として所有者、有効期限、および補償コントロールが必要です。
可用性が低下しなかったことをどのように証明しますか？
各ステージの前後で、拒否、リリースの成功、再起動、SLO、およびテナントエラーを比較します。長時間実行されるサービスだけでなく、ローリングアップグレードや短時間で終了するJobも再現して検証します。