はじめに
先日AWS SignerについてのLTをしてきました。
AWS Signerとは何か？については以下をご覧ください。
このLTでは、署名の検証にKyvernoというOSSを使用しています。
LTの中でも紹介しましたが、このKyvernoというのはかなり多機能なポリシーエンジンで、コンテナイメージ検証の他、リソース制約やラベル検証など多くの機能を有しています。
本ブログでは、Kyvernoにどういった機能があるかを整理していきます。
Kyverno
Kyvernoとは
改めてKyvernoとは、Kubernetesで使用可能なポリシーエンジンで、YAML形式でルールを記載することができます。
Kubernetes Admission Webhookとして動作するため、クラスタへのリソース登録・更新・削除のタイミングにポリシーを適用できます。
なお、KyvernoはCNCF(Cloud Native Computing Foundation)のGraduatedプロジェクトです。GraduatedはCNCFのプロジェクトステージの中で最も成熟したステージを示すものであり、本番利用に耐えうるような信頼性が高いとされています。
本記事のサンプルコードは、執筆時点で広く使われている"ClusterPolicy"形式(JMESPath記法)で記載しています。
ただし、Kyverno v1.17(2026年2月リリース)より"ClusterPolicy"および"Policy"は非推奨(Deprecated)となり、CEL(Common Expression Language)記法を使った新しいポリシータイプ("ValidatingPolicy"など)への移行が推奨されています。2026年中に削除予定とアナウンスされているため、新規で書く場合はCEL記法を選ぶことをおすすめします。
以下も併せてご覧ください。
参考: Kyverno 公式 Migration to CEL Guide
Kyvernoの主な機能
Kyvernoには大きく分けて以下の機能があります。
VerifyImages(署名検証)
コンテナイメージの署名を検証してくれます。LTではこの機能をメインで紹介しました。
信頼できる署名が付与されていないコンテナイメージのデプロイを拒否することができ、サプライチェーン攻撃などへの対策として非常に有効です。
AWS Signerとの組み合わせでは、"kyverno-notation-aws"というプラグインを使ってEKS上でこれを実現しています。詳細はLT資料をご覧ください。
VerifyImages(本章)とValidate(次章)について、日本語だとどちらも「検証」ですが、役割が異なります。
- VerifyImages：コンテナイメージのデジタル署名を検証します。ECRなどのコンテナレジストリに問い合わせて「誰が署名したか」を確認してくれるため、マニフェストの内容検証とは仕組みが異なります。
- Validate：KubernetesリソースのYAMLの内容を検証します。「latestタグが使われていないか」「必須ラベルがあるか」といったマニフェスト上のルールチェックをしてくれます。
Validate(検証)
リソースが特定のルールを満たしているかを検証します。満たしていない場合はデプロイを拒否することができます。
例えば、以下のようなことが実現できます。
- "latest"タグのコンテナイメージのデプロイ拒否
- セキュリティコンテキストの設定強制(root実行の禁止など)
- 必須ラベルが設定されていないリソースの拒否
# 例: latestタグのコンテナイメージを拒否するポリシー
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-latest-tag
spec:
validationFailureAction: Enforce
rules:
- name: require-image-tag
match:
any:
- resources:
kinds:
- Pod
validate:
message: "イメージタグの指定は必須です。"
pattern:
spec:
containers:
- image: "*:*"
- name: validate-image-tag
match:
any:
- resources:
kinds:
- Pod
validate:
message: "latestタグの使用は禁止されています。"
pattern:
spec:
containers:
- image: "!*:latest"
Mutate(変換)
リソースの内容を自動的に変換・補完してくれます。
例えば、以下のようなことが実現できます。
- リソース作成時に自動でラベルやアノテーションを付与
- デフォルト値の自動設定(リソース制約など)
- サイドカーコンテナの自動注入
# 例: Podに自動でラベルを付与するポリシー
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-labels
spec:
rules:
- name: add-team-label
match:
any:
- resources:
kinds:
- Pod
mutate:
patchStrategicMerge:
metadata:
labels:
managed-by: kyverno
Generate(生成)
あるリソースの作成をトリガーに、別のリソースを自動生成してくれます。
例えば、以下のようなことが実現できます。
- Namespace作成時に、デフォルトのNetworkPolicyやRBACリソースを自動生成
- ConfigMapやSecretの自動コピー(他Namespaceへの配布)
# 例: Namespace作成時にNetworkPolicyを自動生成するポリシー
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-networkpolicy
spec:
rules:
- name: default-deny
match:
any:
- resources:
kinds:
- Namespace
generate:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
name: default-deny-ingress
namespace: "{{request.object.metadata.name}}"
synchronize: true
data:
spec:
podSelector: {}
policyTypes:
- Ingress
Cleanup(クリーンアップ)
TTL(Time To Live)ベースでリソースを自動削除してくれます。
例えば、以下のようなことが実現できます。
- テスト用Podを一定時間後に自動削除
- 古くなったリソースの自動クリーンアップ
# 例: 作成から1時間後にPodを削除するポリシー
apiVersion: kyverno.io/v2beta1
kind: CleanupPolicy
metadata:
name: cleanup-old-pods
spec:
match:
any:
- resources:
kinds:
- Pod
selector:
matchLabels:
temporary: "true"
conditions:
any:
- key: "{{ time_since('', '{{ target.metadata.creationTimestamp }}', '') }}"
operator: GreaterThanOrEquals
value: 1h
schedule: "*/5 * * * *"
Kyvernoのモード
"validationFailureAction"の設定によって、ポリシー違反時の挙動を変えることができます。
| モード | 挙動 |
|---|---|
| "Enforce" | ポリシー違反のリソースを拒否する |
| "Audit" | ポリシー違反を記録するが、拒否はしない |
最初は"Audit"モードで運用して既存リソースへの影響を確認し、問題がなければ"Enforce"に切り替えるというアプローチがよさそうですね。
おわりに
Kyvernoの機能を整理してみました。
Kyvernoはコンテナイメージ検証だけでなく、検証/変換/生成/クリーンアップと幅広い機能を持つポリシーエンジンです。「Kubernetes上でこういう制御をしたいな...」と思ったとき、Kyvernoで解決できるケースは多そうです。
近日、実際に各機能を試してみた記事も投稿予定ですので、お楽しみに～～！