Koray Oksay氏（CNCFアンバサダー）は、組織がKyvernoをセキュリティチームの管轄下に置くことが多く、Kubernetesの設定の検証、root権限で動作するコンテナのブロック、コンテナセキュリティ標準の適用などに利用した後、その機能の大部分を使わないままにしていると考えている。Oksay氏によれば、この認識上の分類はKyvernoの役割を、悪い設定を阻止する「ゲート」に限定してしまう。一方で、プラットフォームチームはKyvernoを基盤となる構成要素として利用し、その上にサービスや運用ルールを構築できる。
この見解は、筆者が2023年のKCD Munichカンファレンスで「Kyvernoを使用したKubernetesワークロードのセキュリティ保護」というタイトルの発表を行った経験に基づいている。プロダクション環境で3年間取り組んだ後、関心はガバナンス、CEL、プラットフォームのセルフサービスへと移ったと述べており、Kyvernoを「ポリシーエンジン」と表現するだけでは、その範囲を十分に説明できなくなったという。
セキュリティ分類だけではなぜ不十分なのか？
Oksay氏はKyvernoのセキュリティ機能を否定しているわけではない。このプラットフォームは、安全でない設定をブロックし、Pod Security Standardsを適用し、コンテナイメージの署名を検証できる。しかし、セキュリティだけに結び付けると、ポリシーを主な目的が拒否である障壁として捉えるモデルが定着し、成功が阻止したデプロイ数で測られるようになる。
これに対して筆者は、Kyvernoの主な機能を、検証、変更、生成、イメージ検証の4つに分類している。検証機能は障壁モデルに直接属する。一方、変更はリソースをクラスターに投入する前に変更し、生成は特定のイベントに応じて新しいリソースを作成する。また、イメージ検証は脅威のブロックだけでなく、イメージへの信頼の構築に重点を置く。そのため、4つの機能のうち3つは構築的な性質を持つが、多くの組織は検証ポリシーしか利用していないと考えている。
プラットフォームの中核コンポーネントとは何か？
Oksay氏は「中核コンポーネント」という表現を、プログラミング言語での用法に近い意味で使っている。つまり、小さく理解しやすく、組み合わせてより大きなシステムを構築できる構成要素である。この構成要素がプラットフォームで実際の役割を果たすには、開発者から複雑さを隠し、自動的な保証を提供し、他の構成要素と統合し、手作業の依頼やサポート待ちに依存せずセルフサービスで利用できなければならない。
この意味で、Kyvernoのポリシーは、Pod、Service、ConfigMap、Crossplaneのコンポジションなどのコンポーネントに似ている。組織が採用するルールを、プラットフォーム内の自動的な動作へと変換するからだ。
プラットフォームチームはどのように利用するのか？
- 名前空間の準備：名前空間の作成時に、KyvernoはデフォルトのNetworkPolicy、ResourceQuota、LimitRange、RoleBindingsを生成できる。これにより、開発者が一連の手作業を覚えておく必要なく、準備済みの名前空間が表示される。
- サイドカーコンテナの注入：受け入れ段階で、監視エージェント、ネットワークエージェント、シークレット同期コンテナをPod仕様に追加できるため、Deploymentファイルをシンプルに保てる。
- イメージ参照の書き換え：nginx:1.25のような参照をmirror.internal/nginx:1.25に変換し、各開発者が手作業でプレフィックスを追加しなくても、プル操作を内部ミラー経由にできる。
- デフォルトのリソース要求の追加：CPUとメモリの要求を指定していないPodをブロックする代わりに、適切な値を注入し、必要に応じて変更できる。
- 所有権ラベルの設定：値が明確な場合はチーム、コストセンター、環境のラベルを追加でき、曖昧さが影響を及ぼす場合はそれらを強制できる。
実際には何が変わるのか？
これらの利用方法には、組織上の判断を目に見えない自動的な保証へと変換するという1つの考え方が共通している。ルールは、高い権限を持つコンテナの禁止のようなセキュリティ上のものでも、リソース制限の適用のような運用上のものでも、各リソースをコストセンターのラベルに結び付けるような財務上のものでもよい。こうしたルールは、Wikiやチェックリスト、1人のエンジニアの知識にとどまるのではなく、コードとして記述されたポリシーとなり、Gitに保存され、GitOpsツールとKyvernoを通じて適用される。
この視点では、ポリシーを、組織の意図を表現するためのプラットフォームのインターフェースとして扱うことが提案される。これを適用すると、Kyvernoの機能は異なるレベルへと変わる。検証はガードレールを提供し、変更は開発者のための「舗装された道」を描き、生成はテンプレートや初期構成を提供し、イメージ検証は信頼を構築する。
また、チームはポリシーを、バージョン、ユーザー、廃止サイクル、追跡可能な例外を持つプロダクトとして扱うようになる。ポリシーの展開は、監査、警告、段階的な強制の順に開始できる。筆者はさらに、Argo CDやFluxが所有していると見なすリソースをポリシーが変更する場合に、調整上の課題が生じる可能性にも言及しており、同期ループにつながることがある。
Oksay氏が示す結論は、Kyvernoをセキュリティガイドとしてのみ読むと、そのインターフェースと機能の大部分が見えなくなるということだ。氏の見解では、Kyvernoはクラスターの入口に立つ守衛ではなく、プラットフォームチームの見解をリソースやアプリケーションの実際の動作に結び付けるレイヤーである。