公開2026.09.03更新2026.09.27 Kubernetes・コンテナ

Kyvernoとは？Kubernetesのポリシー適用の仕組みとCEL移行を解説

Kyvernoは、Kubernetesのアドミッション制御にポリシーを差し込み、リソースの設定が社内ルールに合っているかを作成時点で判定するポリシーエンジンです。ポリシー自体をKubernetesのリソースとして宣言できるため、専用言語を覚えずにYAMLとCEL式で条件を書けます。CNCFでは2026年3月24日にGraduated（卒業）へ昇格し、2026年9月時点の最新版は1.19系（1.19.0・2026年8月20日公開）です。この記事では、3系統のコントローラが分担する内部構造、v1.19で非推奨になったClusterPolicyからCELポリシー型への移行、Kubernetes標準のValidatingAdmissionPolicyとの役割分担、OPA Gatekeeperとの選び分け、導入が見合う組織条件を実装目線で整理します。

まとめ：Kyverno導入判断とCELポリシー移行の結論

Kyvernoを入れる価値が出るのは、複数チームが同じクラスタへ自由にマニフェストを投げる環境です。レビューで防いでいる特権コンテナや未署名イメージ、ラベル欠落を、APIサーバー側で機械的に落とせます。逆にクラスタを1チームが専有し、マニフェストがすべてCIを通ってから適用される構成では、導入は障害点を1つ増やすだけの結果になりがちです。

実装面の結論は3つです。1つ目は、いまから書くポリシーをClusterPolicyではなく新しいCELベースの型で作ること。ClusterPolicyはv1.19で正式に非推奨となり、v1.20（2026年11月予定）で削除の予定です。2つ目は、最初からDenyで止めずAuditで観測期間を置き、既存ワークロードの違反件数を数えること。3つ目は、Webhook応答不能時の設定がクラスタ全体のデプロイ可否に直結すると理解し、タイムアウトと除外対象を先に決めることです。

Kyvernoがアドミッション制御のどこに入り何を強制するのか

Kyvernoの理解は、APIサーバーの処理順序のどこに割り込むのかを押さえると早くなります。

APIサーバーのアドミッションフェーズで動く3系統のコントローラ

kubectlやCIから送られたリソースの作成要求は、認証と認可を通った後にアドミッション制御のフェーズへ入ります。Kyvernoはここへ動的なWebhookとして登録され、APIサーバーからリソースの内容を渡されて判定を返す仕組みです。拒否と判定されたリソースは、etcdに書かれる前に弾かれます。つまりKyvernoが守るのは「クラスタに入る瞬間」であり、すでに動いているPodを後から止める仕組みではありません。

内部の役割は3系統に分かれます。アドミッション要求へ同期で応答する系統、既存リソースを定期的に走査して違反を洗い出す系統、結果をレポートリソースへ書き出す系統です。この分離により、強制はしないまま違反状況だけを可視化する運用が成立します。前提となるKubernetes本体の構造はKubernetesの仕組みとDockerとの違いで確認してください。

検証・変更・生成・イメージ検証という4系統のポリシー動作の違い

Kyvernoのポリシーは4系統の動作を持ちます。第一が検証で、条件に合わないリソースを拒否するか記録として残します。第二が変更で、リソースにラベルやsecurityContextの設定を差し込んで通す動作です。第三が生成で、namespaceの作成を引き金にNetworkPolicyやSecretを自動で作ります。第四がイメージ検証で、署名と証明を確認して未署名のイメージを拒否する動作です。

実務でまず効くのは検証と変更の組み合わせです。検証だけでは開発チームへの差し戻しが発生し続けますが、変更を併用すれば足りない設定をKyvernoが補って通す形にできます。イメージ検証は取得元のレジストリを絞る制御と組み合わせて初めて効くもので、取得元の管理そのものはコンテナレジストリの種類と選び方、署名や証明を含む供給網全体の防御はサプライチェーンセキュリティの実装判断で整理しています。

Rego不要でYAMLとCELだけでポリシーを記述できる設計上の意味

Kyvernoが支持されてきた理由は、ポリシーがKubernetesのリソースとして表現される点にあります。CRDで定義された独自リソースなのでkubectlで取得でき、GitOpsのリポジトリへ他のマニフェストと同じ形で置けます。レビューも既存の流れに乗せられる点が実務的です。この拡張の仕組み自体はKubernetes APIのリソース構造とCRD拡張で解説しているとおりです。

条件式の記述にはCELを使います。CELはKubernetes本体のアドミッションポリシーでも採用されている式言語で、専用の処理系を別に覚える必要はありません。実行結果はPolicyReportとClusterPolicyReportに残るため、監視系との接続はレポート監視かメトリクス化で組めます。クラスタ側の監視設計はKubernetes監視のメトリクスとアラート閾値の設計を土台にしてください。

ポリシー型の世代交代：ClusterPolicy廃止とCELポリシーへの移行

2026年にKyvernoを触るなら、ここが最大の判断事項です。ネット上のサンプルは削除予定の書式で書かれたものが多く残ります。

v1.19で非推奨になったClusterPolicyと削除予定のv1.20

従来のKyvernoは、ClusterPolicyとPolicyという2つのリソースの中にルールを並べる形でした。この書式が世代交代の対象です。公式の廃止スケジュールでは、1.17系（2026年2月）で廃止予定のマークが付き、1.18系（2026年4月）はクリティカル修正のみとなり、1.19系（2026年8月）が正式な非推奨かつレガシー型を完全サポートする最終リリースになりました。削除は1.20系（2026年11月予定）で、CleanupPolicyも同じ対象です。

実務的な意味は2つです。新規のポリシーを旧書式で作ると数か月で書き直しが発生すること、既存のClusterPolicy資産を抱えたまま1.20系へ上げるとポリシーが失われかねないことです。バージョンを上げない選択もできますが、セキュリティ修正が旧系に続く保証はありません。移行の期限は外から決まっている前提で計画してください。

ValidatingPolicyなど5種類のCELポリシー型と適用範囲の対応

新しい書式では、動作ごとに専用のリソース型が用意されました。1つのリソースへ複数動作を混在させるのではなく、目的に応じて型を選ぶ構造です。

ポリシー型	担う動作	主な用途
ValidatingPolicy	検証と拒否	特権Podやラベル欠落の排除
MutatingPolicy	設定の変更	既定ラベルや制限値の付与
GeneratingPolicy	リソース生成	namespace作成時の初期設定
ImageValidatingPolicy	イメージ検証	署名と証明の確認
DeletingPolicy	予定削除	期限切れリソースの掃除

各型にはnamespaceスコープの亜種があり、特定namespaceの中だけで有効なポリシーをそのnamespaceの管理者へ委ねられます。1.19系の時点で、新しい型は旧来のルールベースの書式と機能面で同等になったと公式が明言しました。「新書式では書けない要件があるから移行できない」という状態は解消済みです。

移行を段取りする手順とkyverno migrateでの版数更新の位置づけ

移行は一括変換ではなく段階的な置き換えとして設計します。順序は次のとおりです。

現行のClusterPolicyを棚卸しし、検証・変更・生成のどの動作に当たるかで分類する
影響の小さい検証系から、対応するValidatingPolicyへ書き換える
書き換えたポリシーをPlaygroundと既存のCLIテストで確認する
新旧を同時に有効にせず、置き換えた範囲から旧ポリシーを外す
すべて置き換えた後に1.20系への更新を計画する

手戻りを減らす材料も揃っています。既存のKyverno CLIテストは変更なしで再利用でき、ストレージバージョンの更新にはkyverno migrateコマンドが用意され、Playgroundも新しいポリシー型へ対応済みです。1.19系ではCRDが専用のkyverno-apiチャートで管理される構成に変わったため、Helmで導入している環境は更新手順の見直しが要ります。ポリシーレポートの仕組みには変更がなく、監視の設定はそのまま引き継げます。

Kubernetes標準のValidatingAdmissionPolicyとの役割分担

ここを整理せずに導入すると、標準機能で足りる要件にツールを1つ増やす結果になります。

ValidatingAdmissionPolicyのGA後もKyvernoが要る理由

Kubernetesは1.30でValidatingAdmissionPolicyを安定版にしました。CELで条件を書いてリソースを拒否する仕組みが本体に入ったため、単純な検証だけならWebhookを外部に置く必要はありません。APIサーバー内で評価される分、応答遅延と障害点が減ります。変更側のMutatingAdmissionPolicyも整備が進み、本稿時点ではベータ段階の扱いです。

それでもKyvernoが残る理由は、標準機能の範囲が検証と単純な変更に限られる点です。namespace作成を引き金にした他リソースの生成、イメージの署名と証明の検証、既存リソースを走査した違反レポート、期限に応じた削除は標準側にありません。要件が「Podのフィールドを弾く」だけなら標準機能で足り、生成やイメージ検証やレポートまで要るならKyvernoが要ります。

autogenでKubernetes標準ポリシーへ変換する使い方と制約

1.19系のValidatingPolicyには、Kubernetes標準のValidatingAdmissionPolicyを自動生成する設定があります。spec.autogenの配下で有効にすると、Kyvernoで書いたポリシーから標準ポリシーが作られ、評価がAPIサーバー内で完結する形になります。Webhookの往復が消えるため、応答時間とKyverno Pod障害時の影響を同時に下げられる構成です。

勘所は、生成できるのが標準側で表現可能な検証だけという点です。生成や変更を含むポリシー、外部データを参照するポリシーは対象外で、従来どおりWebhook経由の評価になります。現実的な構成は併用です。件数が多く単純な検証は標準ポリシーへ寄せ、生成やイメージ検証はKyvernoに残す振り分けを設計時に決めておくと、後からWebhookの負荷に悩まされません。

OPA Gatekeeperとの選び分けをRegoとCELの運用コストで判断する

比較の軸は機能差ではなく、ポリシーを誰が書いて誰が保守するかという体制側にあります。

Regoの表現力とYAMLとCELの学習コストを運用体制で比べる

OPA Gatekeeperはポリシー記述にRegoを用います。Regoは汎用のポリシー言語で、複雑な条件や集合演算を簡潔に書ける表現力が持ち味です。反面そのために専任の書き手が必要になりやすく、書いた本人の異動後に誰も直せないポリシーが残る事故も起きます。Kyvernoは宣言的なYAMLとCEL式で書くため、マニフェストを読めるメンバーなら追加の言語習得なしに読み書きへ参加できます。

判断は単純です。ポリシーを書く担当を1人か2人に固定でき、その人がRegoを扱えるなら、Gatekeeperの表現力は資産になります。保守をインフラ担当の持ち回りで回す体制なら、読み手の裾野が広いKyverno側が現実的でしょう。両方を同一クラスタへ入れる構成は、アドミッションの評価順序と拒否理由の切り分けが難しくなるため避けてください。

Kubernetes以外の対象へポリシーを広げる要件がある場合の選択

Gatekeeperを選ぶ明確な理由は、同じポリシーをKubernetes以外でも使う場合です。OPAはAPIゲートウェイやCIの判定にも組み込めるため、全社で1つのポリシー資産を共有したい要件に向きます。マイクロサービス間の認可判定とクラスタのアドミッション制御を同じRegoで共通化する構成が代表例です。

一方でKyverno側も、spec.evaluationのmodeをJSONにすればKubernetes外のペイロードを扱えるため、この差は以前より縮んでいます。CIでインフラ構成の計画ファイルを検証する程度なら単体で足ります。全社横断のポリシー基盤としてOPAを既に運用している組織はGatekeeperで揃え、Kubernetesの統制から着手する組織はKyvernoから入る切り分けが実務的です。

Kyvernoを本番クラスタへ導入する順序と可用性設計の実装判断

導入で事故るのは、ポリシーの中身ではなく強制の切り替え方とWebhookの設定です。

Audit運用から段階的にDenyへ切り替える導入順序の作り方

ValidatingPolicyのvalidationActionsにはAuditとDenyがあり、最初に置くべきはAuditです。Auditなら違反してもリソースは通り、結果はポリシーレポートへ記録されます。この状態で1週間から2週間ほど回し、既存ワークロードの違反件数を数えてください。ここを飛ばしてDenyから始めると、CIのデプロイが一斉に落ちて切り戻しになります。

切り替えの順序も決めておきます。新規のnamespaceだけをDenyの対象にし、既存側は違反の修正が済んだところから順にDenyへ移す形です。例外が必要な範囲はPolicyExceptionで宣言的に切り出し、ポリシー本体へ条件を書き足す形は避けてください。例外がリソースとして残れば、いつ誰が何を除外したかを追えます。

failurePolicyの設定がクラスタ全体の可用性を左右する理由

ここが最大の設計判断です。KyvernoはWebhookとして呼ばれるため、Kyverno側が応答しないときにAPIサーバーがどう振る舞うかを決める必要があります。応答不能時に要求を拒否する設定なら統制は保たれる一方、Kyvernoの障害がクラスタ全体のデプロイ停止に直結する構造です。逆に通す設定なら可用性は守られ、その代わりKyvernoが落ちている間はポリシーがすり抜けます。

実務的な落とし所は4点です。第一に、対象リソースをmatchConstraintsで絞り、Kyvernoが呼ばれる範囲そのものを小さくすること。第二に、Webhookのタイムアウトを既定の10秒より短く置き、遅延がAPIサーバーの詰まりへ広がらないようにすること（設定範囲は1秒から30秒です）。第三に、kube-systemなどクラスタ基盤が入るnamespaceを除外し、Kyverno自身の復旧経路を塞がないこと。第四に、Podを複数レプリカで冗長化してノード分散を効かせることです。拒否設定を選ぶなら、この4つを揃えてからにしてください。

Kyverno採用が見合う組織条件と見送るべき運用体制の境界線

ここからは判断の章です。導入すべき条件と、入れても運用負荷が回収できない構成を示します。

Kyvernoの導入が見合うクラスタ規模とチーム体制の3つの条件

次の3条件のいずれかに当たるなら、Kyvernoを入れる価値があります。1つ目は、複数チームが同じクラスタへ直接マニフェストを適用していること。適用経路が分散した状態ではレビューで統制を保てず、APIサーバー側で機械的に落とす仕組みが要ります。2つ目は、監査や認証制度への対応で「禁止設定が入っていない証跡」を出す必要があること。ポリシーレポートは違反の有無を継続的に記録するため、点検を都度の手作業から外せます。

3つ目は、namespaceの払い出しに定型の初期設定が伴うこと。NetworkPolicyやリソースクォータ、共通Secretを毎回手で作っている運用は、生成ポリシーで自動化できます。規模面の参考として、LinkedInは230以上のクラスタ・50万以上のノードで毎分20,000以上のアドミッションリクエストを処理しており、Bloomberg・Coinbase・Spotifyなども採用企業として公表されています。大規模クラスタでの性能を理由に見送る必要はありません。

Kyvernoを見送るべき環境と点検から着手する体制設計の進め方

見送るべき構成もはっきり言えます。クラスタを1チームが専有し、すべてのマニフェストがCIのlintと承認を経てから適用される環境では、導入はアドミッション経路に障害点を1つ増やすだけの結果になりがちです。この場合はCI側の検証を厚くするほうが影響は小さく済みます。統制対象がPodのフィールド検証に限られる場合も、Kubernetes標準のValidatingAdmissionPolicyで足ります。

マネージドKubernetesの標準機能で代替できる範囲も確認してください。Podのセキュリティ設定を制限する仕組みがサービス側に備わっている場合もあり、要件がそこへ収まるならツールを増やす必要はありません。各サービスの機能差はGKEのAutopilotとStandardの違いと使い分けが比較の入口になります。そもそもKubernetes自体が自社に見合うかを判断する段階なら、コンテナオーケストレーションが自社に必要かの判断を先に読んでください。分岐点は「マニフェストの適用経路を人のレビューで統制しきれているか」の一点です。

導入する場合も、入れた時点では完成しません。ポリシーの追加と例外の棚卸し、Kubernetes版数更新に合わせた互換性の確認、レポートに溜まる違反の処理という3つの定常業務が発生します。何を禁止すべきかは、クラスタ構成とコンテナイメージの実態を点検して初めて決まるものです。洗い出しを自社だけで進めるのが難しい場合は、脆弱性診断・セキュリティ診断で現行設定とイメージの点検を切り出し、その結果をポリシーの初期セットへ落とす進め方もあります。実害のある設定から禁止対象にするほうが、公開されたポリシー集を丸ごと当てるより現場の抵抗は小さく済みます。

よくある質問

Kyverno導入の検討時に挙がる質問を、実装上の前提とあわせて整理します。

Kyvernoは無料で使えますか？

Kyverno本体はオープンソースで、ライセンス費用はかかりません。CNCFのプロジェクトとして開発され、2026年3月にGraduated（卒業）レベルへ昇格しました。卒業要件に第三者のセキュリティ監査とCNCF TAG Security & Complianceの評価が含まれる点は、素性の確認材料になります。実費はPodが消費するクラスタリソースと、ポリシーを保守する工数です。

KyvernoとOPA Gatekeeperはどちらを選ぶべきですか？

ポリシーを書いて保守する体制で決めてください。Kubernetesのマニフェストを読めるメンバーが持ち回りで保守するならKyverno、Regoを扱える担当が固定でいて全社横断のポリシー資産を作るならGatekeeperが向きます。機能面では両者が近づいており、生成やイメージ検証まで含む守備範囲と専用言語が不要な点がKyvernoの持ち味です。

ClusterPolicyで書いた既存のポリシーはいつまで使えますか？

1.19系がClusterPolicyを完全にサポートする最終リリースで、削除は1.20系（2026年11月予定）に予定されています。1.20系へ上げる前に、CELベースのポリシー型へ書き換える作業が必要です。単位は動作ごとで、検証はValidatingPolicy、変更はMutatingPolicy、生成はGeneratingPolicyへ振り分けます。

Kyvernoが停止するとクラスタは動かなくなりますか？

Webhookの応答不能時の振る舞いをどう設定したかで変わります。拒否する設定なら、Kyvernoが応答しない間は対象リソースの作成と更新が止まります。通す設定なら作成は続き、その間はポリシーが適用されません。対象を絞る・タイムアウトを短く置く・基盤のnamespaceを除外する・冗長化するの4点で影響を抑えてください。

Kyvernoは既に動いているリソースの違反も検出できますか？

検出できます。バックグラウンドスキャンを有効にすると、既存リソースを定期的に走査して結果をPolicyReportとClusterPolicyReportへ書き出します。アドミッション制御は新規の作成と更新にしか効かないため、導入前から動くワークロードの違反はこの走査で洗い出す形です。導入初期はこのレポートを違反の残件リストとして使ってください。