Kyverno（キベルノ）

2025年11月6日

Kyverno（キベルノ）

英語表記: Kyverno

概要

Kyvernoは、Kubernetesクラスターにおけるポリシー管理をネイティブに行うために設計されたポリシーエンジンです。Kubernetesのカスタムリソース（CRD）としてポリシーを定義できる点が最大の特徴であり、YAMLファイルを通じて宣言的にルールを記述できます。オーケストレーション環境におけるセキュリティ、コンプライアンス、ベストプラクティスを自動的に適用し、特にGitOpsのパイプラインに組み込むことで、リソースがクラスターにデプロイされる前の段階で、定義された望ましい状態（Desired State）から逸脱していないかを厳格にチェックする役割を果たします。

詳細解説

ポリシー管理におけるKyvernoの位置づけ

Kyvernoは、私たちが現在議論している「オーケストレーション（Kubernetes, OpenShift）→ GitOpsと宣言的運用 → ポリシー管理」という文脈において、非常に重要な位置を占めています。GitOpsでは、インフラの状態をコード（Gitリポジトリ）で管理し、それをクラスターに適用します。しかし、コードがすべて正しく書かれているとは限りませんし、セキュリティ要件を満たしている保証もありません。

ここでKyvernoが登場します。Kyvernoは、Kubernetesの動的アドミッションコントローラーとして機能します。これは、リソースの作成、更新、削除といったAPIリクエストがKubernetes APIサーバーに到達した直後、実際にetcdに永続化される直前のタイミングで、リクエストを傍受し、定義されたポリシーに基づいて検証を行う仕組みです。これにより、意図しない設定や、セキュリティリスクのある設定がクラスターに持ち込まれることを防ぐ「最後の防衛線」として機能するのです。

Kubernetesネイティブなポリシー定義の利点

他のポリシーエンジンがRegoのような専用のポリシー言語を必要とするのに対し、Kyvernoのポリシーは標準的なKubernetes YAML（ClusterPolicy または Policy）として記述されます。これは、Kubernetesエンジニアにとって学習コストが極めて低く、既存のGitOpsワークフロー（例えば、Argo CDやFlux）にポリシー定義ファイルをそのまま組み込めるという大きなメリットがあります。Gitリポジトリにポリシーを配置し、他のアプリケーションリソースと同じようにバージョン管理できるため、まさに「ポリシー管理の宣言的運用」を実現しています。これは非常に画期的だと感じています。

Kyvernoの主要機能

Kyvernoは、単にリソースを拒否するだけでなく、クラスターの状態を積極的に管理するための3つの主要な機能を提供します。

検証（Validation）:
- ポリシーに違反するAPIリクエストを拒否します。
- 例: 「すべてのPodには、必ずメモリとCPUのリソース制限（limits）が設定されていなければならない」といったコンプライアンス要件を強制します。
変更（Mutation）:
- APIリクエストが許可される前に、リソース定義を自動的に修正し、ポリシーに準拠させます。
- 例: 「特定のラベルが欠けている場合、デプロイメントに自動的にそのラベルを追加する」といった、環境固有の標準設定を強制的に適用します。これにより、ユーザーが設定を忘れても自動で修正されるため、運用効率が大幅に向上します。
生成（Generation）:
- あるリソースの作成をトリガーとして、関連する新しいリソースを自動的に生成します。
- 例: 「新しいNamespaceが作成された際、そのNamespace内に標準的なセキュリティ設定を適用するRoleBindingやNetworkPolicyを自動で作成する」といった、初期設定の自動化に利用されます。これは、マルチテナント環境のポリシー適用において、非常に強力な機能です。

これらの機能を通じて、KyvernoはGitOps環境における「ポリシーのコード化」と「継続的なコンプライアンス」の維持を支えているのです。

具体例・活用シーン

具体的な活用例

セキュリティ強化:
- 特権コンテナの利用禁止を強制する。
- すべてのコンテナイメージは、信頼できるレジストリからのみプルされるように制限する。
- Kubernetesの推奨するセキュリティコンテキスト（SecurityContext）の利用を義務付ける。
コスト管理と運用標準化:
- すべてのデプロイメントに、プロジェクト名や担当チームを示す特定のラベル（cost-center: xxxなど）が必須であることを検証する。
- 開発環境と本番環境で異なるデフォルトのリソース制限値を自動的に適用する。

初心者向けのアナロジー：マンションの管理規約

Kyvernoの役割を理解するために、「ITインフラという名の巨大なマンションの管理規約」に例えてみましょう。

Kubernetesクラスターは、多くのテナント（アプリケーション）が入居する大規模なマンションです。GitOpsツール（例えば、デプロイヤー）は、新しい入居者（リソース）を連れてくる仲介業者だと考えてください。

管理規約（ポリシー）の定義: マンションの管理組合（セキュリティチームや運用チーム）は、「ゴミ出しのルール」「騒音の制限」「火気使用の制限」といった規約（Kyvernoポリシー）を定めます。
入居審査（Validation）: 仲介業者が新しい入居者を連れてきたとき、Kyvernoという名の管理人がドアのところでチェックします。「この人は火気を持ち込もうとしていないか？（特権コンテナではないか？）」もし規約に違反していれば、入居は即座に拒否されます。これが検証です。
設備付与（Mutation）: 入居者が持ち込んだ家具（リソース定義）に、規約で定められた標準的な安全装置（必須ラベルやセキュリティ設定）が不足していた場合、管理人がその場で自動的に取り付けてしまいます。これが変更です。
共用部の整備（Generation）: 新しいフロア（Namespace）が作られたら、管理人は自動的にそのフロア専用の消防設備（NetworkPolicy）や防犯カメラ（RBAC設定）を設置します。これが生成です。

Kyvernoがいるおかげで、誰もが規約を守り、安全で秩序だったマンション運営（クラスター運用）が実現できるのです。手動でチェックする手間が一切かからないため、運用担当者としては本当にありがたい存在です。

資格試験向けチェックポイント

Kyverno自体が直接出題されることは稀ですが、その機能が担う役割は、応用情報技術者試験や高度試験の「セキュリティ」や「システムアーキテクチャ」分野で問われる概念と深く関連しています。

キーワードの理解（ITパスポート/基本情報技術者）:
- ポリシー管理: システムの標準化、コンプライアンス、セキュリティを維持するためにルールを適用する仕組み。
- 宣言的運用（GitOps）: 望ましい状態を定義し、システムがそれを自動的に維持するアプローチ。Kyvernoはこの実現を強力に支援します。
概念の適用（応用情報技術者）:
- 動的アドミッションコントローラーの役割: APIリクエスト処理パイプラインのどの段階でポリシーチェックが行われるのかを理解しましょう。リソースが永続化される前の「防御のフック」として機能します。
- Validate, Mutate, Generateの使い分け: それぞれの機能が、セキュリティ、標準化、自動化のどの側面を担っているのかを明確に説明できるようにしておくことが重要です。特にMutationは、エラーを拒否するのではなく修正するという点で非常に強力です。
出題パターン:
- 「Kubernetes環境において、セキュリティポリシーの逸脱を防ぎ、かつリソース定義を自動的に修正する仕組みとして適切なものはどれか？」といった形で、ポリシーエンジンの役割が問われる可能性があります。GitOpsの実現において、手動チェックを排除し、コンプライアンスをコード化する役割を担う点を理解しましょう。