Kyvernoマスタークラス: パターンマッチングで完成させる宣言型Kubernetesセキュリティガイド

6月 5, 2026

—

こんにちは！Kubernetesセキュリティの強力な防衛策、Kyvernoマスターシリーズの7回目です。🛡️

前回まで、私たちはポリシーの頭脳とも言える変数とJMESPathを学びました。その知識を基に、実際にリソースを検証し、ブロックする実践的な防御技術を学ぶ番です。

今日取り上げる内容は、Kyvernoの華とも呼ばれるvalidateルールと、ポリシー運用の核となる戦略であるfailurePolicy、validationFailureActionです。深く掘り下げて、クラスターセキュリティの専門家になりましょう！🚀

🏗️ 1. validateルールの基本構造とパターンマッチング

validateルールは、ユーザーが作成しようとしているリソースが、私たちが定義した「パターン」に合致するかどうかを確認するプロセスです。

🔹 基本構造

最も単純なvalidateポリシーは、リソースの特定のフィールド値が私たちが望む値であるかを確認します。

YAML

validate:
  message: "이유를 설명하는 메시지 (사용자에게 노출됨)"
  pattern:
    spec:
      containers:
      - name: "*" # すべてのコンテナについて
        securityContext:
          allowPrivilegeEscalation: false # この値は必ずfalseである必要があります

🔸 パターンマッチングの魔法

Kyvernoのパターンマッチングは非常に直感的です。リソースのYAML構造をそのまま辿りながら値を比較します。

ワイルドカード (*): 0個以上の文字にマッチします。(例: image: “nginx:*”はすべてのnginxバージョンを許可)
疑問符 (?): ちょうど1つの文字にマッチします。
空でない (?[*): そのフィールドが必ず存在し、値が空であってはならないことを意味します。
条件付きマッチング: 数値や文字列に対して、>, <, >= などの演算子を使用できます。

🚦 2. failurePolicy: Webhook接続失敗時のあなたの選択は？

Kubernetes APIサーバーとKyverno間の通信に問題が発生した場合（ネットワーク障害、Kyverno Podのダウンなど）に、クラスターがどのように反応すべきかを決定する非常に重要な設定です。

🟢 Ignore (デフォルト値)

動作方法: Kyvernoが応答しない場合、「仕方ない」としてリソース作成を許可します。
利点: Kyvernoの障害がサービス全体のデプロイ障害につながりません。(可用性優先)
欠点: セキュリティチェックなしで危険なリソースがデプロイされる可能性があります。

🔴 Fail

動作方法: Kyvernoが応答しない場合、「危険だから、とりあえず止めろ！」としてリソース作成をブロックします。
利点: セキュリティを徹底的に維持できます。(セキュリティ優先)
欠点: Kyvernoに問題が発生すると、クラスター内のすべてのリソース作成/変更操作が麻痺します。

💡 専門家のヒント: 運用環境ではIgnoreを基本としつつ、Kyvernoを高可用性(HA)で構成して障害確率を低減するのが一般的な戦略です。

⚖️ 3. validationFailureAction: Audit(監査) vs Enforce(強制)

ポリシーに違反した場合にKyvernoがどのようなアクションを取るかを決定します。これはポリシーの「モード」と理解すると簡単です。

👁️ Audit (監視モード)

動作: リソース作成を許可しますが、違反事項をPolicyReportに記録します。
用途: 新しいポリシーを初めて導入する際に、既存サービスにどのような影響を与えるかを把握するために使用します。(ドライランに類似)

🚫 Enforce (ブロックモード)

動作: ポリシーに違反したリソース作成を即座にブロックし、ユーザーにエラーメッセージを送信します。
用途: すでに検証済みのポリシーを通じて、クラスターセキュリティガイドラインを強力に強制する場合に使用します。

💻 実践総合例: セキュリティ強化ポリシー

上記の3つの主要な概念をすべて盛り込んだ実践的なポリシーコードを見てみましょう。

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-secure-defaults
spec:
  # 1. ポリシー違反時に即時ブロック (運用段階)
  validationFailureAction: Enforce 
  
  # 2. Kyverno障害時でもAPIサーバーは続行 (可用性保証)
  # 注: この設定は実際のWebhookConfigurationに反映されます。
  failurePolicy: Ignore 
  
  background: true
  rules:
  - name: check-image-registry
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "허용되지 않은 레지스트리에서 이미지를 가져올 수 없습니다. (우리 회사 전용 사용 필수)"
      pattern:
        spec:
          containers:
          - image: "my-company.registry.io/*" # パターンマッチングの活用

🚀 運用者のための戦略的移行ガイド

新しいセキュリティポリシーをクラスターにデプロイする際は、以下の手順を踏むのが最も安全です。

ステップ1 (Auditモード): validationFailureAction: Auditでデプロイします。数日間PolicyReportを監視し、どのチームのどのリソースが影響を受けるかを確認します。
ステップ2 (通知と修正): 違反レポートに基づいて関連チームに連絡し、リソースの修正を依頼します。
ステップ3 (Enforceへの移行): すべてのリソースが準備できたら、Enforceに切り替えてセキュリティを確立します。

🌟 終わりに

今日は、Kyvernoポリシーの核となる防御メカニズムであるvalidateと、運用戦略の設定について見てきました。

パターンで入念に検査し、
failurePolicyで障害状況に備え、
validationFailureActionで柔軟に、あるいは強力にセキュリティを適用する方法を習得しました。🛠️

これで皆さんは、単にポリシーを作成するだけでなく、実際のサービス環境に安全にポリシーを導入する方法を知る熟練した運用者となりました！💪 ご不明な点があれば、いつでもコメントに残してください！😊