# 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

```bash
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

```yaml
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

```yaml
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.

## Cross-links

* [Policy Exception Governance Pack](https://github.com/D3One/Product-Security-Gitbook/blob/main/09-container-and-kubernetes-security/policy-exception-governance-pack.md)
* [OPA and Policy Enforcement](/cloud-kubernetes-and-infrastructure-security/index-1/opa-and-policy-enforcement.md)
* [Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index-1/kyverno-deep-pages.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.