【ITニュース解説】Admission Control in Kubernetes: Where Policy Actually Gets Enforced

Kubernetesにおけるアドミッションコントロールは、クラスターの安全性と信頼性を保つために非常に重要な仕組みである。これは、ユーザーやシステムがKubernetes APIサーバーに対して何らかの操作（例えば、新しいPodの作成や設定の変更など）をリクエストした際に、その操作がクラスターのセキュリティポリシーや運用ルールに合致しているかを確認し、必要であれば変更したり、拒否したりする関門の役割を果たす。過去には、デバッグ目的で一時的に許可されたはずの「特権」を持つ設定がそのまま残ってしまったり、監視ツールのために誤ってホストのファイルシステムにアクセスできるような設定が追加されたり、誰も作成した覚えのない広範囲な権限を持つサービスアカウントが存在したりすることがあった。アドミッションコントロールは、そうした意図しない、あるいは望ましくない設定がクラスターに適用されるのを未然に防ぎ、ポリシーを強制する場所である。この仕組みがどのように動作するかを理解することは、なぜ特定のポリシーがあるクラスターでは機能し、別のクラスターでは機能しないのかを解明する上で不可欠だ。

Kubernetes APIサーバーへのリクエストは、まず「認証」フェーズを通過し、誰がリクエストを行っているかを確認する。次に「認可」フェーズで、そのユーザーが要求された操作を行う権限を持っているかを確認する。そして最後に「アドミッション」フェーズへと進む。アドミッションフェーズはさらに二つの段階に分けられる。一つ目は「変更アドミッション（Mutating Admission）」で、これは受信したオブジェクト（例えばPodの定義など）を実際に変更する可能性がある。例えば、セキュリティ強化のために特定のサイドカーコンテナを自動的にPodに追加したり、環境変数を注入したりすることがこれに該当する。二つ目は「検証アドミッション（Validating Admission）」で、これはオブジェクトの内容を検証し、ポリシーに違反していればリクエストを拒否するが、オブジェクト自体を変更することはない。Kubernetesに組み込まれているServiceAccountやResourceQuotaといったコントローラーも、このアドミッションチェーンの中でWebhookと並行して動作する。

このアドミッション処理の順序は、実際の運用において非常に重要である。例えば、変更アドミッションのWebhookがPodにサイドカーコンテナを注入した後、その変更後のPodの定義を検証アドミッションのWebhookが見ることになる。もし検証ルールが元のPodの定義を前提として書かれていると、変更された後のPodがポリシーに違反していると判断され、意図せず拒否される可能性がある。そのため、ポリシーが最終的な状態に基づいて判断する必要がある場合は、オブジェクトを変更するWebhookが先に実行され、その後に検証ルールが適用されるように順序を制御する必要がある。この順序付けは、Webhookの設定にあるreinvocationPolicyや、Webhook自体の配置順序によって制御される。

Kubernetesには、Pod Security Admission（PSA）という組み込みのアドミッションコントロールがある。これはWebhookインフラストラクチャを必要としないため、簡単に導入できる強力なセキュリティ機能だ。PSAは、特定の名前空間に対してprivileged、baseline、restrictedのいずれかのセキュリティレベルをラベルとして適用する。特にrestrictedレベルは非常に厳格なセキュリティ基準を課す。具体的には、コンテナがrootユーザー以外のユーザーで実行されることを強制したり、ルートファイルシステムを読み取り専用にしたり、不要なLinuxケーパビリティ（特殊な権限）を削除したり、seccompプロファイルを適用したりするなど、多くの制約が含まれる。

PSAの利点は、前述の通り組み込みであるため設定が容易な点だが、その制限は「粒度」にある。このセキュリティレベルは名前空間全体に適用されるため、もし一つのKubernetesクラスター内で異なるセキュリティ要件を持つ複数のワークロードが混在している場合、それらを別々の名前空間に分割するか、すべてのワークロードにより厳しいレベル（例えばrestricted）を適用する必要がある。後者の場合、一部のワークロードが動作しなくなる可能性も考えられる。そのため、PSAを本番環境に適用する前に、まずwarnモードで設定し、どのようなPodが拒否されることになるかを確認することで、予期せぬ障害を防ぐことができる。以下は名前空間にrestrictedレベルを適用しつつ、警告モードも有効にするYAML設定の例だ。

Copy
1apiVersion: v1
2kind: Namespace
3metadata:
4  name: payments
5  labels:
6    pod-security.kubernetes.io/enforce: restricted
7    pod-security.kubernetes.io/warn: restricted

より高度なポリシー管理には、GatekeeperやKyvernoのような「ポリシーエンジン」が利用される。これらのエンジンは、ポリシーをコードとして表現し、パラメーターを持たせることができる点が大きな特徴だ。例えば、「ホストパスボリュームの使用を禁止する」というポリシーを定義する場合、特定のパスだけは許可するというパラメーターを設定できる。これにより、全くホストパスを許可しないクラスターと、特定の監視エージェントのための一つのパスだけを許可するクラスターで、同じポリシー定義を再利用できる。

ポリシーエンジンが提供するこのような柔軟性は、ポリシーの強制だけでなく、監査証跡の観点からも重要である。パラメーター化された制約は、どのような条件で何が許可されたのかを明確に記録として残すため、セキュリティレビューの際に非常に役立つ。一方、動作がコンテナイメージの中にしか存在しないWebhookと比較すると、より透明性が高いと言える。

ポリシーエンジンの運用には二つの重要な考慮点がある。一つは、セキュリティに関連するコントロールについては、Webhookが「フェイルクローズ（fail closed）」であるべきだという点だ。これは、もしポリシーエンジンが何らかの理由で利用できない状態になった場合、セキュリティ上のリスクを避けるために、リクエストを拒否するべきだという考え方である。もう一つは、ポリシーエンジン自体もKubernetesクラスター内で動作するという事実である。そのため、ポリシーエンジンが動作している名前空間は、自身が適用するポリシーの対象から除外する必要がある。この除外設定は、単に発見されるのを待つのではなく、明確に文書化しておくことが不可欠である。

アドミッションポリシーが期待通りに機能し続けるためには、「ポリシーを維持する」という課題も重要である。アドミッションポリシーの失敗の典型的な例は、インシデント発生時に一時的に許可された例外が、その後も削除されずに残ってしまうことだ。これを防ぐためには、期限付きの例外をポリシーリポジトリに記録し、その例外を許可した所有者と有効期限を明記することが有効である。また、定期的に現在アクティブな例外のリストをレポートとして生成することで、例外の無秩序な蓄積を可視化し、適切なタイミングで対応できるようにすることが重要である。これにより、クラスターのセキュリティは継続的に保たれ、意図しない設定や脆弱性が生まれるのを防ぐことができる。