Kyverno Master Class: A Declarative Kubernetes Security Guide with Pattern Matching

Hello everyone! This is the seventh session of the Kyverno Master Series, a powerful defense for Kubernetes security. 🛡️

In previous sessions, we learned about variables and JMESPath, which can be considered the brains of policies. Now, based on that knowledge, it’s time to learn practical defense techniques to actually validate and block resources.

Today, we will cover the validate rule, often called the “flower” of Kyverno, and the core operational strategies: failurePolicy and validationFailureAction. Let’s deep dive and become cluster security experts! 🚀

---

🏗️ 1. Basic Structure of validate Rule and Pattern Matching

The validate rule is the process of checking whether the resource a user intends to create matches the ‘pattern’ we have defined.

🔹 Basic Structure

The simplest form of a validate policy checks if a specific field value of a resource matches our desired value.

YAML

validate:
  message: "이유를 설명하는 메시지 (사용자에게 노출됨)"
  pattern:
    spec:
      containers:
      - name: "*" # For all containers
        securityContext:
          allowPrivilegeEscalation: false # This value must be false

🔸 The Magic of Pattern Matching

Kyverno’s pattern matching is very intuitive. It compares values by following the YAML structure of the resource directly.

• Wildcard (*): Matches zero or more characters. (e.g., image: “nginx:*” allows all nginx versions)
• Question Mark (?): Matches exactly one character.
• Not Empty (?*): Means the field must exist and its value must not be empty.
• Conditional Matching: Operators like >, <, >= can be used for numbers or strings.

---

🚦 2. failurePolicy: Your Choice When Webhook Connection Fails?

This is a very important setting that determines how the cluster should react when there’s a communication issue between the Kubernetes API server and Kyverno (e.g., network failure, Kyverno Pod downtime).

🟢 Ignore (Default)

• How it works: If Kyverno doesn’t respond, it “can’t be helped” and allows resource creation.
• Pros: Kyverno failures do not lead to overall service deployment failures. (Availability first)
• Cons: Risky resources can be deployed without security checks.

🔴 Fail

• How it works: If Kyverno doesn’t respond, it says “It’s dangerous, stop it now!” and blocks resource creation.
• Pros: Security can be strictly maintained. (Security first)
• Cons: If Kyverno has issues, all resource creation/modification operations within the cluster will be paralyzed.

💡 Expert Tip: In production environments, it’s a common strategy to default to Ignore, but configure Kyverno for high availability (HA) to reduce the probability of failures.

---

⚖️ 3. validationFailureAction: Audit (Observe) vs Enforce (Mandate)

This determines what action Kyverno will take when a policy is violated. It’s easy to understand this as the ‘mode’ of the policy.

👁️ Audit (Monitoring Mode)

• Behavior: Allows resource creation but records violations in the PolicyReport.
• Purpose: Used when introducing new policies for the first time, to understand their impact on existing services. (Similar to Dry-run)

🚫 Enforce (Blocking Mode)

• Behavior: Immediately blocks the creation of resources that violate the policy and sends an error message to the user.
• Purpose: Used to strongly enforce cluster security guidelines with already validated policies.

---

💻 Practical Comprehensive Example: Security Hardening Policy

Let’s look at a practical policy code that incorporates all three core concepts above.

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-secure-defaults
spec:
  # 1. Immediately block on policy violation (production phase)
  validationFailureAction: Enforce 
  
  # 2. Even if Kyverno fails, the API server proceeds (ensuring availability)
  # Note: This setting is reflected in the actual 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/*" # Utilizing pattern matching

---

🚀 Strategic Transition Guide for Operators

When deploying new security policies to a cluster, following these steps is the safest approach:

1. Step 1 (Audit Mode): Deploy with validationFailureAction: Audit. For a few days, monitor the PolicyReport to identify which teams and resources are affected.
2. Step 2 (Notification and Remediation): Based on the violation report, contact the relevant teams and request resource modifications.
3. Step 3 (Transition to Enforce): Once all resources are ready, switch to Enforce to establish security.

---

🌟 Conclusion

Today, we explored Kyverno policy’s core defense mechanisms, validate, and operational strategy settings.

• You’ve learned how to meticulously check with patterns,
• prepare for failure scenarios with failurePolicy, and
• apply security gently or strongly with validationFailureAction. 🛠️

Now, you are no longer just creating policies, but have become a skilled operator who knows how to safely implement policies in a real service environment! 💪 Feel free to leave any questions in the comments! 😊

---