Kyverno Kubernetes Native Policy Management

• validate — enforce structural and field constraints (expressed with Kubernetes YAML patterns).
• mutate — modify objects before they are persisted (apply defaults, add labels, inject sidecars, set imagePullPolicy).
• generate — create new Kubernetes resources automatically in response to events (e.g., new Namespace creation).

​

Quick reference: rule types

​

1) Validate

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/*"

• validationFailureAction: Enforce blocks non-compliant resources. Start with Audit to log violations without blocking.
• match scopes which resources the rule applies to.
• pattern uses Kyverno’s YAML pattern matching. For simple to moderate checks this method is concise and easy to maintain.
• If your requirements need arbitrarily complex queries or computations, consider Gatekeeper (OPA + Rego), which is more expressive.

​

2) Mutate

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 behaves like a Kubernetes strategic-merge patch. It will add or update the provided label.
• To avoid overwriting an existing label value, use conditional mutation logic or JSON Patch (RFC 6902) with Kyverno’s patchesJson6902.
• Mutations happen before validation webhooks, enabling a pattern where you apply defaults (mutate) and then assert required fields (validate).

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

    - name: require-team-label
      match:
        any:
          - resources:
              kinds: ["Deployment", "Service"]
      validate:
        message: "Resource must have managed-by: platform-team label"
        pattern:
          metadata:
            labels:
              managed-by: "platform-team"

​

3) Generate

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"]

• Default NetworkPolicy to lock down new namespaces
• ResourceQuota and LimitRange per namespace
• Create ServiceAccount and RBAC bindings automatically for teams

• Use Kyverno when you want mutation (defaults, injections) and straightforward validation expressed in YAML patterns. It’s fast to author and maintain for platform policies.
• Use Gatekeeper (OPA + Rego) when you need highly expressive, complex validation logic that requires full programmatic capability.
• Both can run in the same cluster; evaluate per-policy which tool is the best fit.

​

Debugging Kyverno

# List all cluster policies and check readiness
kubectl get clusterpolicy
# Example output columns:
# NAME                        ADMISSION   BACKGROUND   READY
# Check PolicyReports (audit-mode violations)
kubectl get policyreport -A
kubectl get clusterpolicyreport

# See violation details for a specific namespace
kubectl describe policyreport -n payments

# Check Kyverno admission controller logs if webhooks are failing
kubectl logs -n kyverno deployment/kyverno

• READY: false for a ClusterPolicy usually indicates a YAML syntax error or invalid policy field — check the Kyverno controller logs for details.
• If policies do not seem to target objects you expect, verify the match/exclude criteria and resource kinds.
• If webhooks are failing, inspect the Kyverno pod logs and the webhook configuration in kubectl get validatingwebhookconfigurations / kubectl get mutatingwebhookconfigurations.

• Kyverno policies are native Kubernetes YAML—no separate policy language required.
• Kyverno supports validate, mutate, and generate in a single policy resource.
• Start in Audit mode, review PolicyReports, iterate, then move to Enforce.
• Use Kyverno for mutation and common platform validation patterns; use Gatekeeper (Rego) for complex validation logic. They can coexist in the same cluster.

• Kyverno official docs: https://kyverno.io/
• Gatekeeper (OPA) docs: https://open-policy-agent.github.io/gatekeeper/
• Rego policy language: https://www.openpolicyagent.org/docs/latest/policy-language/rego/
• Kubernetes admission controllers: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
• Kyverno Best Practices: https://kyverno.io/docs/best-practices/