PS Product SecurityKnowledge Base

🧩 Kyverno Deep Pages

Intro: Kyverno is often adopted because it stays close to Kubernetes YAML and supports validation, mutation, generation, image verification, and policy reports. It works best when teams treat it as a delivery control plane with governance around exceptions, not just a pile of rules.

Core implementation notes

  • use validation for required metadata, image rules, Pod security, and high-value configuration guardrails;
  • use mutation carefully for low-risk defaults and standardization, but do not let mutation hide unclear ownership;
  • use generation for baseline namespace resources only where drift and lifecycle are understood;
  • keep background reporting enabled where it helps adoption, but be clear which rules are enforce versus report-only.

Policy exceptions

Kyverno supports PolicyException, but they are disabled by default and should be enabled intentionally with namespace restrictions and governance guardrails.

Practical guardrails

  • keep exceptions narrow by namespace, object name, selector, or CEL condition;
  • require expiry and owner metadata in Git;
  • limit who can create exceptions through RBAC and GitOps review;
  • review whether a policy should be fixed instead of repeatedly excepted.

Install

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

Sample policy: require team label

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-team-label
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: check-team-label
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Pods must define a team label."
        pattern:
          metadata:
            labels:
              team: "?*"

Sample policy exception

apiVersion: kyverno.io/v2
kind: PolicyException
metadata:
  name: allow-build-latest-tag
  namespace: policy-exceptions
spec:
  exceptions:
    - policyName: restrict-image-tag
      ruleNames: [no-latest-tag]
  match:
    any:
      - resources:
          namespaces: [ci]
          names: [image-builder-*]

Use cases

  • require labels and ownership metadata;
  • restrict registries or mutable tags;
  • generate baseline resources into namespaces;
  • produce policy reports for rollout evidence;
  • enforce or verify image-signing expectations.