Kyverno Kubernetes Native Policy Management

​

Overview: Kyverno rule types

• validate — check resources and reject non-compliant objects (similar to Gatekeeper, but expressed in YAML pattern matching instead of Rego).
• mutate — modify resources (add defaults, labels, env vars, etc.) via a mutating admission webhook.
• generate — create related resources automatically when a matching resource is created (for example, create a default-deny NetworkPolicy when a Namespace is created).

​

Validate, Mutate, Generate — concise explanation

• Validate: Uses YAML pattern matching and wildcards to assert required fields and values. Rejections occur when the resource does not match the allowed pattern.
• Mutate: Runs as a mutating admission webhook and modifies the incoming resource before it is persisted. Useful for adding default labels, setting imagePullPolicy, injecting environment variables, etc.
• Generate: Automatically creates another resource in response to a matching resource creation (common for guardrails like NetworkPolicy, ResourceQuota, LimitRange, or service accounts).

​

Examples

​

1) Validation example — restrict image registries

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: >
          Images must be from
          registry.company.com
        pattern:
          spec:
            containers:
              - image: "registry.company.com/*"

• A single ClusterPolicy holds all rules (no templates, no Rego).
• spec.validationFailureAction: Enforce causes non-compliant objects to be rejected. Use Audit while testing.

​

2) Mutate example — add a default label

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-labels
spec:
  rules:
    - name: add-team-label
      match:
        any:
          - resources:
              kinds: ["Deployment", "Service"]
      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              managed-by: platform-team

• patchStrategicMerge merges labels and will not overwrite an existing label value; it adds the label only if missing.
• Use patchJson6902 for precise add/remove/replace operations at JSON paths.

​

3) Combine mutate + validate in one policy (pattern)

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-managed-by-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: add-managed-by-label
      match:
        any:
          - resources:
              kinds: ["Deployment", "Service"]
      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              managed-by: platform-team

    - name: require-managed-by-label
      match:
        any:
          - resources:
              kinds: ["Deployment", "Service"]
      validate:
        message: "The 'managed-by=platform-team' label is required"
        pattern:
          metadata:
            labels:
              managed-by: "platform-team"

• Resources without the label will have it added automatically by the mutate rule.
• If the label is removed later, the validate rule will reject updates that do not match (subject to webhook ordering and timing).

​

4) Generate example — create a default-deny NetworkPolicy per Namespace

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: default-deny-ingress
spec:
  rules:
    - name: generate-default-netpol
      match:
        any:
          - resources:
              kinds: ["Namespace"]
      generate:
        kind: NetworkPolicy
        apiVersion: networking.k8s.io/v1
        name: default-deny-ingress
        namespace: "{{request.object.metadata.name}}"
        data:
          spec:
            podSelector: {}
            policyTypes: ["Ingress"]

• The namespace field references the created Namespace using the expression {{request.object.metadata.name}}.
• Use generate to ensure guardrails are created automatically for new namespaces.

​

Kyverno vs Gatekeeper — when to choose what

• Kyverno documentation
• Gatekeeper / OPA documentation
• Kubernetes admission controllers overview

​

Debugging, status and common commands

• kubectl get clusterpolicy shows Kyverno ClusterPolicy objects and the READY column (policy loaded and valid).
• Kyverno emits PolicyReport and ClusterPolicyReport resources for audit-mode violations.
• Check controller logs when webhook errors occur.

# List all cluster policies and their status
kubectl get clusterpolicy

# Check policy reports (audit-mode violations)
kubectl get policyreport -A
kubectl get clusterpolicyreport

# Describe a PolicyReport for a specific namespace (example: payments)
kubectl describe policyreport -n payments

# Check Kyverno controller logs
kubectl logs -n kyverno deployment/kyverno

• READY = false: usually indicates invalid policy YAML or a schema mismatch. Inspect kubectl describe clusterpolicy <name> and Kyverno logs.
• Policies not taking effect: verify match criteria are correct; it’s common for match scope to not include the resources you expect.
• No rejections while in Enforce: ensure the policy truly matches the resources and the pattern is correct.
• Webhook errors: check Kyverno controller health and logs; confirm webhook configurations and certificates.

​

Key takeaways

• Kyverno uses pure Kubernetes YAML — no extra language required.
• One policy resource can include validate, mutate, and generate rules.
• Adopt a safe rollout: audit mode first, review PolicyReports, then switch to enforce.
• Choose Kyverno when you need mutation or YAML-native policies; choose Gatekeeper when Rego’s expressiveness is required.
• Kyverno and Gatekeeper can coexist in the same cluster.

• Kyverno docs: https://kyverno.io/docs/
• Gatekeeper: https://open-policy-agent.github.io/gatekeeper/