ポリシーをどこで執行するか
一言でいうと
パイプラインは素早いフィードバックを、アドミッションはAPIリクエストの執行を、継続的な点検はすでに存在するリソースの違反の発見を担います。ポリシーがあるという事実と、実際のリクエストを検査したという事実は、別です。
なぜ1か所では足りないのか
例のシナリオ: 決済チームのCIが、署名のないイメージを拒否します。ところが、運用者が別の経路からデプロイすると、そのCIは実行されません。逆に、アドミッションだけを置くと、ビルドを終えたあとで初めてエラーに出会います。すでに起動しているワークロードは、ポリシーを新しく作ったからといって自動的に是正されることもありません。
3つの場所をつなげますが、同じ検査を3回コピーはしません。共通ルールのバージョンと例外の一覧を管理し、それぞれの場所で何を入力として検査したかを残します。デプロイの成功率だけを見ず、適用対象の数、違反の数、検査エラーと例外の期限切れも、合わせて見ます。
どう動くのか
リクエストの許可と、現在の状態の点検
| 場所 | 確認する証拠 | これだけではわからないこと |
|---|---|---|
| CI | 検査対象のdigest、ルールのバージョン、終了コード | CIを迂回したAPIリクエスト |
| アドミッション | 対象のリクエスト、適用範囲、許可・拒否の結果 | ポリシー導入前に作成されたリソースの現在の違反 |
| 継続的な点検 | 点検の時刻、全体の対象数、違反の一覧 | 次のリクエストが必ず拒否されるかどうか |
アドミッションの保証は、マッチしたリクエストと設定の範囲の中で成り立ちます。namespaceSelector、リソース・操作の選択、例外とWebhookのエラー処理まで確認します。WebhookのfailurePolicy: Ignoreは、呼び出しエラーを無視して進めます。Webhookが正常なレスポンスで明示的に拒否したものを許可するという意味ではありません。Failはエラーのときも拒否するため、可用性と復旧の経路を合わせて設計する必要があります。Kubernetesの動的アドミッション
ミューテーション(mutating)のあとに、検証(validating)が来ます。ミューテーションが必要なラベルを埋めたなら、検証は変わったオブジェクトを検査して許可することがあります。これは、検証が実行されなかったという意味ではありません。検証は、最終的なオブジェクトがルールを満たすかを確認する場所です。
ポリシーのAuditモードとAPI監査ログは違います
ポリシーエンジンのAuditモードは、違反を観察し、導入の影響を計算するために使われます。機能と、既存のリソースの点検範囲は、エンジンごとに確認する必要があります。Kubernetes APIの監査ログは、リクエストの活動の記録です。ログを有効にしただけで、ポリシー違反をブロックしたり、すべての既存リソースを再検査したりはしません。
導入計画には、観察期間、修正の担当者、強制への切り替え条件を書きます。例外には、対象・理由・承認者・期限を付け、期限切れが実際に執行されるかを確認します。急ぎの例外を、恒久的なネームスペースの除外に変えると、その空間のその後のリクエストもずっと抜けてしまうことがあります。
NetworkPolicyとmTLSは、互いの代わりになりません
標準のNetworkPolicyは、主にL3/L4の接続範囲を制限します。ラベル・IP・ポートで許可する対象を選びますが、TLSによる暗号化や、証明書に基づく相互認証は提供しません。サービスメッシュやアプリケーションのmTLSは、身元を認証して通信を暗号化し、誰がどの操作をできるかは、別の認可ポリシーで決めます。KubernetesのNetworkPolicyの範囲と限界
NetworkPolicyを執行するネットワークプラグインが必要です。標準のポリシーの観点で選択されていないPodは、その方向について分離されていない状態であり、実際の到達性には、ほかのファイアウォール・プラットフォームのポリシーも影響します。デフォルト拒否を導入するときは、DNSと必要な依存関係の通信を先に一覧にして、分離されたテスト空間で確認します。本番全体にデフォルト拒否を一度に入れて接続を切ることは、検証ではありません。
現場での姿
例のシナリオ: 署名の検証が成功し続けていたのに、ポリシーはteam-aだけを選択しており、実際のサービスはteam-bにありました。レポートの成功だけを読むと、検査範囲が空だったという事実を見逃します。
テストの表を先に作ります。許可するリクエストは成功し、同じ対象の署名のないリクエストは拒否される必要があります。選択範囲を外れたリクエストがどう処理されるかも記録します。タイムアウトのテストは、自分が所有する分離された環境でだけ実施します。ネットワークも、許可されたクライアントの成功と、許可されていないクライアントの失敗を、合わせて確認します。片方だけを見ると、サーバーが落ちてすべての接続が失敗した状態を、セキュリティの成功と勘違いすることがあります。
その次に読むこと
次の記事では、digest、署名、SBOM、provenanceを区別し、秘密の本文を複製せずに、監査の証拠を残す方法を見ます。この単元は、設計と判断を練習する理論・クイズであり、実際のポリシーエンジンの動作をすべて検証したラボという意味ではありません。