Lesson 07 — Kyverno

Learning Objectives

By the end of this lesson, you will be able to:

Explain the purpose of Kyverno
Understand how Kyverno integrates with Kubernetes admission control
Distinguish between namespaced Policies and ClusterPolicies
Create validation policies using Kubernetes-native YAML
Mutate resources to apply approved defaults
Generate supporting Kubernetes resources automatically
Verify container image signatures and attestations
Use PolicyReports for continuous compliance
Test policies before deploying them
Deploy Kyverno on Amazon EKS
Design an enterprise Kyverno policy library
Monitor Kyverno availability and policy violations
Manage policy exceptions and staged enforcement

Why This Matters

Kubernetes allows developers to define infrastructure through YAML manifests.

A deployment manifest can create:

Application containers
Service Accounts
Network endpoints
Persistent storage
Public load balancers
Privileged workloads
Access to host resources

This flexibility improves delivery speed, but it also creates security risks.

Without policy enforcement, development teams may deploy:

Containers running as root
Privileged containers
Images from untrusted registries
Images using the latest tag
Workloads without resource limits
Pods with writable root filesystems
Services exposed publicly
Resources without ownership labels
Workloads without approved security controls
Unsigned or unverified container images

Written standards alone cannot prevent these configurations.

Kyverno translates enterprise requirements into Kubernetes-native policies.

Enterprise Security Requirement

↓

Kyverno Policy

↓

Kubernetes API Request

↓

Policy Evaluation

↓

Validate, Mutate, Generate, Verify or Report

Kyverno is especially useful for Kubernetes teams because its policies are written primarily in YAML.

Engineers can manage policies using familiar Kubernetes tools such as:

kubectl
Helm
Git
GitOps controllers
CI/CD pipelines
Kubernetes Custom Resources

What is Kyverno?

Kyverno is a cloud-native policy engine originally designed for Kubernetes.

The name Kyverno comes from a Greek word associated with governing or steering.

Kyverno enables platform and security teams to define policy-as-code for:

Security
Compliance
Governance
Configuration management
Software supply chain protection
Operational standards
Resource automation

Kyverno policies can inspect Kubernetes resources and perform several actions.

Kyverno Capabilities

├── Validate Resources
├── Mutate Resources
├── Generate Resources
├── Verify Container Images
├── Clean Up Resources
├── Report Violations
└── Test Policies Outside the Cluster

Why Kyverno is Kubernetes-Native

Kyverno policies are represented as Kubernetes resources.

They can be:

Written in YAML
Applied using kubectl
Stored in Git
Distributed using GitOps
Managed using Kubernetes RBAC
Audited using Kubernetes APIs
Included in Helm charts
Tested in CI/CD pipelines

A typical policy looks similar to other Kubernetes manifests.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: example-policy
spec:
  rules:
    - name: example-rule
      match:
        any:
          - resources:
              kinds:
                - Pod

This lowers the learning barrier for teams already familiar with Kubernetes YAML.

Kyverno Architecture

Kyverno integrates with the Kubernetes API through admission webhooks and supporting controllers.

Developer or CI/CD Pipeline

↓

Kubernetes API Server

↓

Authentication

↓

Authorisation

↓

Kyverno Admission Controller

↓

Policy Evaluation

├── Validate
├── Mutate
└── Verify Images

↓

Allow, Modify, Warn or Deny

↓

Resource Stored

Additional controllers support:

Background scanning
Policy reporting
Resource generation
Cleanup
Policy processing

Kubernetes Request Lifecycle

A simplified Kubernetes API request follows this sequence:

API Request

↓

Authentication

Who is making the request?

↓

Authorisation

What is the identity allowed to do?

↓

Mutation

Should the resource be modified?

↓

Validation

Does the resource comply with policy?

↓

Resource Persisted

Kyverno participates in the admission process before a requested change is stored.

Authentication, Authorisation and Policy

These controls answer different questions.

Security Layer	Question	Example
Authentication	Who are you?	AWS IAM identity
Authorisation	What are you allowed to do?	Kubernetes RBAC
Admission Policy	Is the requested configuration permitted?	Kyverno validation
Runtime Detection	What is the workload doing?	Falco detection
Continuous Compliance	Does the existing resource remain compliant?	PolicyReport

A developer may be authorised to create Pods but should still be prevented from creating privileged containers.

Developer Has Permission to Create Pods

↓

Developer Submits Privileged Pod

↓

RBAC Allows Pod Creation

↓

Kyverno Evaluates Security Configuration

↓

Privileged Pod Denied

This shows why RBAC and admission policies must work together.

Kyverno Policy Resources

Kyverno commonly uses two policy scopes:

Policy
ClusterPolicy

Policy

A Policy is namespaced.

It applies to resources within the namespace where the Policy is created.

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: require-team-label
  namespace: payments

A namespaced Policy is useful when:

A team manages its own policies
Requirements apply to one namespace
Different namespaces have different standards
Policy ownership is delegated

ClusterPolicy

A ClusterPolicy is cluster-scoped.

It can apply across:

Multiple namespaces
All namespaces
Cluster-scoped resources
Specific resource types
Selected workloads based on labels

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-non-root

ClusterPolicies are commonly used for enterprise-wide security baselines.

Policy and ClusterPolicy Comparison

Capability	Policy	ClusterPolicy
Scope	One namespace	Entire cluster
Namespaced resources	Yes	Yes
Cluster-scoped resources	No	Yes
Team-level governance	Strong	Limited
Enterprise baseline	Limited	Strong
Central security ownership	Possible	Preferred

A mature enterprise may use both.

ClusterPolicy

Enterprise Security Baseline

+

Policy

Application or Namespace-Specific Requirements

Kyverno Policy Structure

A typical policy contains:

Policy

├── Metadata
├── Policy Settings
└── Rules
    ├── Match
    ├── Exclude
    ├── Preconditions
    ├── Validate
    ├── Mutate
    ├── Generate
    └── Verify Images

Each rule defines:

Which resources are evaluated
When the rule applies
What conditions are checked
What action Kyverno performs
What message is returned

Basic Policy Anatomy

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: example-policy
spec:
  validationFailureAction: Audit

  background: true

  rules:
    - name: example-rule

      match:
        any:
          - resources:
              kinds:
                - Pod

      validate:
        message: The Pod does not comply with policy.

        pattern:
          metadata:
            labels:
              owner: "?*"

Policy Settings

Important policy-level settings may include:

Setting	Purpose
`validationFailureAction`	Determines whether validation violations are audited or enforced
`background`	Controls evaluation of existing resources
`rules`	Contains the policy logic
`failurePolicy`	Defines behaviour when policy processing fails
`webhookConfiguration`	Supports advanced webhook behaviour

The exact settings used should be tested against the deployed Kyverno version.

Rule Matching

Kyverno rules use matching criteria to determine which resources should be evaluated.

Matching can consider:

Resource kind
API version
Namespace
Resource name
Labels
Annotations
User identity
Service Account
Kubernetes operation
Namespace labels

Match Any

match:
  any:
    - resources:
        kinds:
          - Pod

        namespaces:
          - production

The rule applies when any matching block is satisfied.

Match All

match:
  all:
    - resources:
        kinds:
          - Deployment

    - resources:
        selector:
          matchLabels:
            environment: production

All matching conditions must be satisfied.

Excluding Resources

Some resources may need to be excluded from a policy.

exclude:
  any:
    - resources:
        namespaces:
          - kyverno
          - kube-system

Exclusions should be:

Narrow
Justified
Documented
Reviewed
Time-limited where possible

Broad exclusions can create policy bypasses.

Kyverno Rule Types

Kyverno supports several major policy actions.

Rule Type	Purpose
Validate	Accept, warn or deny resources based on requirements
Mutate	Modify resources before they are stored
Generate	Create or synchronise related resources
Verify Images	Verify image signatures and attestations
Cleanup	Remove resources according to policy
Report	Record policy evaluation results

Validation Policies

Validation is one of Kyverno’s most common capabilities.

A validation rule checks whether a resource meets required conditions.

Kubernetes Resource

↓

Kyverno Validation Rule

↓

Compliant?

├── Yes → Allow
└── No  → Audit, Warn or Deny

Validation can be used to enforce requirements such as:

Containers must run as non-root
Privileged containers are prohibited
Resource limits are required
Approved registries must be used
Required labels must exist
HostPath volumes are prohibited
LoadBalancer Services are restricted
Images must not use the latest tag

Validation Patterns

Kyverno can validate resources using Kubernetes-style patterns.

Example requirement:

Every Pod must contain an owner label.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-owner-label
spec:
  validationFailureAction: Enforce

  background: true

  rules:
    - name: check-owner-label

      match:
        any:
          - resources:
              kinds:
                - Pod

      validate:
        message: Every Pod must contain an owner label.

        pattern:
          metadata:
            labels:
              owner: "?*"

The ?* pattern requires a non-empty value.

Testing the Required Label Policy

Non-compliant Pod:

apiVersion: v1
kind: Pod
metadata:
  name: unowned-application
spec:
  containers:
    - name: application
      image: nginx:1.27

Attempt to apply it:

kubectl apply -f unowned-pod.yaml

Expected result:

Admission webhook denied the request.

Every Pod must contain an owner label.

Compliant Resource

apiVersion: v1
kind: Pod
metadata:
  name: owned-application

  labels:
    owner: application-team

spec:
  containers:
    - name: application
      image: nginx:1.27

The Pod can be admitted because the required label exists.

Validation Failure Actions

Validation policies can operate in different enforcement modes.

Common operational approaches include:

Audit
Enforce

Warnings may also be configured depending on the policy design and Kyverno version.

Audit Mode

spec:
  validationFailureAction: Audit

Audit mode:

Allows the resource
Records the policy result
Supports PolicyReports
Helps discover existing violations
Reduces rollout disruption

Use Audit when:

Introducing a new policy
Evaluating application impact
Measuring current compliance
Training application teams
Testing policy scope

Enforce Mode

spec:
  validationFailureAction: Enforce

Enforce mode:

Rejects non-compliant resources
Prevents insecure configurations
Provides immediate feedback
Supports mandatory enterprise controls

Use Enforce only after:

Policy testing
Application remediation
Stakeholder communication
Exception planning
Operational validation

Policy Rollout Strategy

Policy Requirement Defined

↓

Policy Written

↓

Local Testing

↓

Audit Mode

↓

Review PolicyReports

↓

Remediate Workloads

↓

Communicate Enforcement Date

↓

Enforce Mode

↓

Continuous Monitoring

A staged approach reduces the risk of breaking applications.

Require Non-Root Containers

Enterprise requirement:

Application containers must run as non-root.

Example policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-run-as-non-root
spec:
  validationFailureAction: Enforce

  background: true

  rules:
    - name: check-run-as-non-root

      match:
        any:
          - resources:
              kinds:
                - Pod

      validate:
        message: Containers must run as non-root.

        pattern:
          spec:
            securityContext:
              runAsNonRoot: true

This example requires Pod-level runAsNonRoot.

An enterprise policy may also inspect container-level security contexts.

Deny Privileged Containers

Unsafe workload:

securityContext:
  privileged: true

Example policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce

  background: true

  rules:
    - name: check-privileged

      match:
        any:
          - resources:
              kinds:
                - Pod

      validate:
        message: Privileged containers are prohibited.

        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: "false"

Production policy testing should include:

Standard containers
Init containers
Ephemeral containers
Pods created through controllers
Infrastructure DaemonSets

Deny Privilege Escalation

Enterprise requirement:

Containers must not permit privilege escalation.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privilege-escalation
spec:
  validationFailureAction: Enforce

  background: true

  rules:
    - name: check-privilege-escalation

      match:
        any:
          - resources:
              kinds:
                - Pod

      validate:
        message: Privilege escalation must be disabled.

        pattern:
          spec:
            containers:
              - securityContext:
                  allowPrivilegeEscalation: false

Require Read-Only Root Filesystems

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-readonly-root-filesystem
spec:
  validationFailureAction: Audit

  background: true

  rules:
    - name: check-readonly-root-filesystem

      match:
        any:
          - resources:
              kinds:
                - Pod

      validate:
        message: Containers must use a read-only root filesystem.

        pattern:
          spec:
            containers:
              - securityContext:
                  readOnlyRootFilesystem: true

Audit mode should be used first because many existing applications may require remediation.

Require Resource Limits

Enterprise requirement:

Every container must define CPU and memory requests and limits.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-requests-and-limits
spec:
  validationFailureAction: Audit

  background: true

  rules:
    - name: check-container-resources

      match:
        any:
          - resources:
              kinds:
                - Pod

      validate:
        message: CPU and memory requests and limits are required.

        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    cpu: "?*"
                    memory: "?*"

                  limits:
                    cpu: "?*"
                    memory: "?*"

Resource controls improve:

Workload stability
Scheduling
Capacity management
Availability
Cost visibility
Denial-of-service resistance

Require Approved Registries

Enterprise requirement:

Production images must come from an approved Amazon ECR registry.

Example approved registry:

123456789012.dkr.ecr.eu-west-2.amazonaws.com

Example policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce

  background: true

  rules:
    - name: validate-image-registry

      match:
        any:
          - resources:
              kinds:
                - Pod

              namespaceSelector:
                matchLabels:
                  environment: production

      validate:
        message: Images must come from the approved Amazon ECR registry.

        pattern:
          spec:
            containers:
              - image: "123456789012.dkr.ecr.eu-west-2.amazonaws.com/*"

This reduces the risk of workloads using untrusted public images.

Deny the Latest Tag

Avoid:

image: company/application:latest

Prefer:

image: company/application:v2.4.1

For stronger immutability:

image: company/application@sha256:exampledigest

Policy objective:

Container Image Uses latest Tag

↓

Kyverno Validation

↓

Deployment Denied

Mutable tags make it difficult to prove exactly which code is running.

Restrict HostPath Volumes

A HostPath volume can expose worker-node files to a Pod.

Unsafe configuration:

volumes:
  - name: host-root
    hostPath:
      path: /

Enterprise policy should:

Deny HostPath by default
Permit only approved infrastructure workloads
Limit approved paths
Require read-only access
Record exceptions
Monitor usage

Restrict Host Namespaces

High-risk settings include:

hostNetwork: true
hostPID: true
hostIPC: true

A policy can deny these settings for standard application namespaces.

System workloads that require host access should use:

Dedicated namespaces
Dedicated Service Accounts
Restricted node groups
Compensating controls
Additional runtime monitoring

Restrict LoadBalancer Services

Unsafe or unapproved exposure:

spec:
  type: LoadBalancer

A Kyverno policy can prevent application teams from creating public load balancers outside approved namespaces.

Service Request

↓

Is Type LoadBalancer?

├── No → Continue
└── Yes
    ↓
    Is Namespace Approved?

    ├── Yes → Continue
    └── No  → Deny

This reduces accidental internet exposure.

Deny EmptyDir or Unsafe Volume Types

Storage policies may restrict:

HostPath
Local volumes
EmptyDir with unsafe usage
Unsupported CSI drivers
Unencrypted storage classes
Sensitive projected volumes

The correct policy depends on application and platform requirements.

Mutation Policies

Mutation policies modify resources before they are stored.

Incoming Resource

↓

Kyverno Mutation Rule

↓

Resource Modified

↓

Validation

↓

Modified Resource Stored

Mutation can be used to:

Add labels
Add annotations
Apply security defaults
Add image pull secrets
Set an approved StorageClass
Add a seccomp profile
Add scheduling constraints
Standardise configuration

Example Mutation — Add a Team Label

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-team-label
spec:
  rules:
    - name: add-team-label

      match:
        any:
          - resources:
              kinds:
                - Pod

              namespaces:
                - development

      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              +(team): platform-engineering

The +() anchor adds the label only when it does not already exist.

Mutation Flow

Developer submits:

metadata:
  name: application

Kyverno stores:

metadata:
  name: application

  labels:
    team: platform-engineering

Example Mutation — Add a Seccomp Profile

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-seccomp
spec:
  rules:
    - name: add-runtime-default-seccomp

      match:
        any:
          - resources:
              kinds:
                - Pod

      mutate:
        patchStrategicMerge:
          spec:
            securityContext:
              +(seccompProfile):
                type: RuntimeDefault

This can help apply a secure default when the Pod does not specify one.

Mutation Benefits

Mutation can:

Reduce developer workload
Apply consistent defaults
Improve platform standardisation
Reduce configuration errors
Accelerate secure onboarding
Support central platform controls

Mutation Risks

Mutation also introduces risks.

These include:

Resources stored differently from submitted manifests
GitOps drift
Unexpected application behaviour
Troubleshooting complexity
Conflicting mutations
Policy ordering challenges
Hidden security assumptions

Mutation should be:

Transparent
Documented
Tested
Observable
Limited to appropriate use cases

Security-critical requirements may be better enforced through validation when teams must explicitly declare the setting.

Validation Versus Mutation

Requirement	Validate	Mutate
Block privileged containers	Preferred	Not appropriate
Require approved registry	Preferred	Not appropriate
Add ownership label	Possible	Useful
Add default seccomp profile	Possible	Useful
Require resource limits	Preferred	Risky to guess values
Add standard annotations	Possible	Useful
Prevent public exposure	Preferred	Not appropriate

Mutation should not be used to hide serious security design problems.

Generate Policies

Generate rules create or synchronise Kubernetes resources when selected events occur.

Trigger Resource Created

↓

Kyverno Generate Rule

↓

Related Resource Created

↓

Optional Synchronisation

Generate policies can create:

Network Policies
ResourceQuotas
LimitRanges
RoleBindings
ConfigMaps
Secrets
PodDisruptionBudgets
Namespace baseline controls

Namespace Onboarding with Generate Rules

When a new namespace is created, Kyverno can automatically generate:

Default-deny Network Policy
ResourceQuota
LimitRange
Standard RoleBinding
Monitoring configuration
Security metadata

New Namespace

↓

Kyverno Generate Policy

├── Default-Deny NetworkPolicy
├── ResourceQuota
├── LimitRange
└── Standard RoleBinding

This makes secure namespace configuration automatic.

Example Generate Policy — Default-Deny Network Policy

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-default-deny
spec:
  rules:
    - name: generate-default-deny-network-policy

      match:
        any:
          - resources:
              kinds:
                - Namespace

      exclude:
        any:
          - resources:
              names:
                - kube-system
                - kube-public
                - kyverno

      generate:
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: default-deny
        namespace: "{{request.object.metadata.name}}"

        synchronize: true

        data:
          spec:
            podSelector: {}

            policyTypes:
              - Ingress
              - Egress

When a namespace is created, Kyverno generates a default-deny NetworkPolicy.

Synchronisation

The following setting keeps the generated resource aligned with policy:

synchronize: true

If the generated resource is changed or removed, Kyverno may restore the desired configuration.

This supports:

Configuration consistency
Drift correction
Standard namespace controls
Central policy management

Generate Policy Risks

Generate policies require careful permissions and governance.

Risks include:

Excessive Kyverno controller permissions
Unintended resource creation
Conflict with GitOps tools
Conflicting ownership
Resource deletion and recreation
Cross-namespace access requirements

Generated resources should have clearly defined ownership.

Image Verification

Kyverno can verify container image signatures and attestations.

Image verification helps answer:

Was the image signed?
Who signed it?
Was it built by an approved pipeline?
Does it contain required attestations?
Is the image from an approved source?
Has the image reference been changed?

Container Image

↓

Signature or Attestation

↓

Kyverno Image Verification

↓

Trusted?

├── Yes → Admit
└── No  → Deny

Software Supply Chain Risk

An attacker may compromise:

Source code
Build dependencies
CI/CD credentials
Build runners
Container registries
Image tags
Deployment manifests

Traditional image scanning alone may not prove that an image came from an approved build system.

Image signing and verification add provenance and authenticity controls.

Image Verification Architecture

Developer Commit

↓

Approved CI/CD Pipeline

↓

Container Build

↓

Image Scan

↓

Image Signing

↓

Amazon ECR

↓

Kyverno Verification

↓

Amazon EKS Deployment

Signature Verification

A signature can prove that an image was signed by an approved identity or key.

Kyverno can integrate with signing approaches such as Sigstore Cosign.

An enterprise policy may require:

Approved public key
Approved certificate identity
Approved keyless signer
Required transparency-log evidence
Required signed digest

Attestation Verification

Attestations provide additional claims about an image.

Examples include:

Build provenance
Vulnerability scan status
SBOM availability
Test results
Source repository
Approved builder identity
Compliance status

Image Signature

Proves image authenticity

+

Attestation

Provides evidence about how the image was built or tested

Example Image Verification Concept

verifyImages:
  - imageReferences:
      - "123456789012.dkr.ecr.eu-west-2.amazonaws.com/*"

    mutateDigest: true
    verifyDigest: true

    required: true

    attestors:
      - entries:
          - keys:
              publicKeys: |-
                -----BEGIN PUBLIC KEY-----
                EXAMPLE-PUBLIC-KEY
                -----END PUBLIC KEY-----

The exact image-verification structure must be aligned with the installed Kyverno version and selected signing model.

Image Digest Mutation

An image may initially be referenced by tag:

application:v2.4.1

Kyverno can resolve it to an immutable digest:

application@sha256:exampledigest

This helps prevent the referenced image from changing after admission.

Image Verification Best Practices

Use immutable image digests.
Verify signatures in production.
Restrict approved signing identities.
Protect signing keys.
Prefer short-lived or keyless signing where appropriate.
Require provenance from approved build systems.
Separate image builders from deployment approvers.
Test verification failure scenarios.
Monitor verification denials.
Maintain emergency procedures.

PolicyReports

Kyverno can create policy reports containing evaluation results.

Policy reports help security and platform teams understand:

Which resources passed
Which resources failed
Which resources were skipped
Which policies generated warnings
Which namespaces contain violations
Which controls need remediation

Policy Reporting Architecture

Kyverno Policies

↓

Admission Evaluation and Background Scanning

↓

PolicyReport Resources

↓

Reporting Controller

↓

Prometheus, Dashboard or Compliance Platform

Namespaced PolicyReport

A PolicyReport generally contains findings for namespaced resources.

kubectl get policyreports -A

ClusterPolicyReport

A ClusterPolicyReport generally contains findings for cluster-scoped resources.

kubectl get clusterpolicyreports

Inspecting a PolicyReport

kubectl describe policyreport -n production

A report may contain results such as:

Result	Meaning
Pass	Resource complied with the policy
Fail	Resource violated the policy
Warn	Resource triggered a warning
Error	Policy evaluation encountered an error
Skip	Rule did not apply or was skipped

Example Compliance Finding

Policy: require-resource-limits

Rule: check-container-resources

Resource: Deployment/payment-api

Namespace: production

Result: Fail

Message: CPU and memory requests and limits are required.

Background Scanning

Background scanning evaluates existing resources against applicable policies.

This is important because resources may:

Pre-date the policy
Have been created during Audit mode
Become non-compliant after a policy update
Be restored from backup
Exist in a newly included namespace
Have drifted from the approved baseline

Existing Kubernetes Resources

↓

Kyverno Background Scan

↓

Policy Evaluation

↓

PolicyReport Results

↓

Remediation Workflow

Admission Versus Background Scanning

Capability	Admission Evaluation	Background Scanning
Evaluates new requests	Yes	No
Evaluates existing resources	Limited	Yes
Blocks non-compliant creation	Yes	No
Supports compliance inventory	Partially	Yes
Detects historical violations	No	Yes
Supports continuous reporting	Yes	Yes

Both are required for enterprise governance.

Cleanup Policies

Kyverno can support resource cleanup based on policy.

Potential use cases include:

Removing expired test resources
Deleting temporary namespaces
Cleaning completed Jobs
Removing outdated resources
Enforcing resource lifetimes
Reducing abandoned cloud costs

Temporary Resource

↓

Cleanup Policy

↓

Expiry Condition Reached

↓

Resource Deleted

Cleanup policies should be tested carefully because deletion is destructive.

Cleanup Security Considerations

Before using cleanup policies:

Confirm the match scope.
Exclude production resources where necessary.
Test in non-production.
Require ownership labels.
Define retention requirements.
Protect evidence needed for investigations.
Monitor deleted-resource events.
Document recovery procedures.

Preconditions

Preconditions allow a rule to run only when specified conditions are satisfied.

Example logic:

Apply Policy Only When:

Environment = Production

AND

Operation = Create or Update

Preconditions help:

Reduce unnecessary evaluations
Implement risk-based controls
Target specific operations
Check request context
Support exceptions
Improve policy performance

Request Context

Policies may use request information such as:

User name
User groups
Operation
Namespace
Resource name
Submitted object
Previous object
Service Account
Admission request details

This enables context-aware controls.

Example:

LoadBalancer Service Requested

AND

Requester Is Not Approved Deployment Pipeline

↓

Deny

Identity-based exceptions should be tightly controlled because deployment identities may be compromised.

Policy Exceptions

Some resources may require temporary exceptions.

Examples include:

Security agents requiring host access
Storage drivers requiring HostPath
Networking components requiring host networking
Legacy workloads that cannot run as non-root
Emergency troubleshooting tools
Infrastructure controllers requiring broad permissions

An exception should never become an undocumented bypass.

Exception Governance

Every policy exception should include:

Exception ID:

Policy Name:

Affected Cluster:

Namespace:

Workload:

Service Account:

Business Justification:

Risk Description:

Compensating Controls:

Owner:

Approver:

Start Date:

Expiry Date:

Remediation Plan:

Narrow Exception Design

Prefer exceptions based on:

Exact policy
Exact rule
Exact namespace
Exact resource name
Exact Service Account
Exact resource labels
Defined expiry date

Avoid:

Excluding entire business units
Excluding all system namespaces
Excluding all DaemonSets
Excluding every resource created by one team
Permanent exceptions without review

Installing Kyverno

Kyverno can be installed using Helm.

Add the Kyverno Helm repository:

helm repo add kyverno https://kyverno.github.io/kyverno/

Update Helm repositories:

helm repo update

Install Kyverno in a dedicated namespace:

helm install kyverno kyverno/kyverno \
--namespace kyverno \
--create-namespace

For production installations, configuration should be reviewed and adapted to the organisation’s:

Cluster size
Availability requirements
Admission request volume
Monitoring architecture
Security requirements
Disaster-recovery procedures

Verify the Installation

Check Pods:

kubectl get pods -n kyverno

Check deployments:

kubectl get deployments -n kyverno

Check services:

kubectl get services -n kyverno

Check Kyverno Custom Resource Definitions:

kubectl get crds | grep kyverno

Check installed policies:

kubectl get clusterpolicies

Kyverno Components

Depending on the deployed version and configuration, a Kyverno installation may contain components responsible for:

Admission processing
Background processing
Cleanup
Policy reports
Resource generation

Kyverno Platform

├── Admission Controller
├── Background Controller
├── Reports Controller
├── Cleanup Controller
├── Policy Resources
├── Policy Exceptions
└── Metrics

Production Installation Considerations

A production deployment should consider:

Multiple replicas
PodDisruptionBudgets
Anti-affinity
Resource requests and limits
Health probes
Monitoring
Certificate management
Admission latency
Failure behaviour
Controller permissions
Upgrade strategy
Backup of policy definitions

Amazon EKS Architecture

Enterprise Identity Provider

↓

AWS IAM

↓

Amazon EKS API Server

↓

Kubernetes Authentication and RBAC

↓

Kyverno Admission Controller

├── Validate
├── Mutate
└── Verify Images

↓

Kubernetes Resources

Meanwhile:

Kyverno Background and Reports Controllers

↓

Existing Resource Evaluation

↓

PolicyReports

↓

Prometheus, Grafana and SIEM

Kyverno on Amazon EKS

Kyverno can support EKS security requirements such as:

Restricting privileged containers
Requiring non-root execution
Requiring approved Amazon ECR registries
Denying mutable image tags
Requiring image signatures
Applying standard labels
Generating Network Policies
Restricting LoadBalancer Services
Requiring resource limits
Controlling Service Account usage
Enforcing EKS workload identity standards
Standardising namespace configuration

Approved Amazon ECR Policy

An enterprise may allow images only from:

Production Amazon ECR Account

↓

Approved Repository

↓

Signed Image

↓

Kyverno Verification

↓

Amazon EKS

Policies should consider:

Multiple AWS accounts
Multiple AWS Regions
Shared-services registries
Disaster-recovery registries
Approved third-party images
Image replication

EKS Workload Identity Policy

An enterprise requirement may state:

Workloads that access AWS services must use an approved Service Account and pod-level identity.

Kyverno can validate that Pods:

Do not use the default Service Account
Specify a dedicated Service Account
Include required identity annotations where applicable
Run in an approved namespace
Do not inherit broad node permissions by design

Example validation concept:

validate:
  message: Application Pods must use a dedicated Service Account.

  pattern:
    spec:
      serviceAccountName: "!default"

Policy testing should confirm compatibility with the chosen EKS identity mechanism.

Namespace Security Automation

Kyverno can automate secure namespace onboarding.

Namespace Created

↓

Kyverno Policies

├── Add Ownership Labels
├── Generate ResourceQuota
├── Generate LimitRange
├── Generate Default-Deny NetworkPolicy
├── Apply Security Annotations
└── Generate Standard RoleBindings

This reduces the risk of incomplete namespace configuration.

Kyverno and Pod Security Admission

Kyverno and Pod Security Admission can be used together.

Pod Security Admission

↓

Standard Pod Security Baseline

+

Kyverno

↓

Custom Enterprise Governance

Pod Security Admission can enforce:

Baseline Pod Security Standard
Restricted Pod Security Standard

Kyverno can add:

Approved registry controls
Required labels
Image verification
Resource requirements
Namespace automation
Service exposure restrictions
Custom workload controls
Policy reports

Kyverno and Gatekeeper

Kyverno and Gatekeeper solve many similar governance problems.

Capability	Kyverno	Gatekeeper
Main Policy Style	Kubernetes-native YAML	Rego-based templates and constraints
Validation	Yes	Yes
Mutation	Yes	Supported
Resource Generation	Native capability	Not a primary capability
Image Verification	Native policy capability	Usually requires additional integration
Policy Reporting	Native reports	Audit and constraint status
Learning Curve	Lower for YAML users	Higher for teams new to Rego
Reusable Logic	Rules and policy patterns	ConstraintTemplates
Complex General Policy Logic	Strong	Very strong
Kubernetes-Native Experience	Very strong	Strong

The enterprise should avoid operating multiple overlapping policy engines without clear ownership.

Selecting Kyverno

Kyverno may be a strong choice when:

Teams prefer YAML
Kubernetes-native policy authoring is important
Mutation is required
Resource generation is required
Image verification is required
PolicyReports are required
Platform teams own policy development
GitOps is used for cluster management

Selecting Gatekeeper

Gatekeeper may be preferred when:

The organisation already uses OPA
Rego expertise exists
Complex reusable policy logic is required
Policies are shared across different OPA use cases
Existing Gatekeeper investments are significant

The decision should consider:

Skills
Policy requirements
Operational complexity
Existing platforms
Reporting needs
Supply chain controls
Long-term ownership

Kyverno CLI

The Kyverno CLI allows policies to be tested outside the cluster.

It can support:

Local testing
CI/CD validation
GitOps workflows
Policy development
Manifest evaluation
Automated test cases

Kyverno Policy

+

Kubernetes Manifest

↓

Kyverno CLI

↓

Pass, Fail, Warn, Error or Skip

Applying a Policy Locally

Conceptual command:

kyverno apply policy.yaml \
--resource deployment.yaml

The output helps determine whether the resource complies before it is submitted to Kubernetes.

Testing Policies

Kyverno policies should be tested using:

Compliant resources
Non-compliant resources
Missing fields
Empty values
Multiple containers
Init containers
Ephemeral containers
Workload controllers
Cluster-scoped resources
Namespaced resources
Excluded namespaces
Helm-generated manifests

Policy Test Cases

Test Case	Expected Result
Non-root container	Pass
Root container	Fail
Approved Amazon ECR image	Pass
Unapproved public image	Fail
Signed image	Pass
Unsigned image	Fail
Workload with limits	Pass
Workload without limits	Fail
Namespace with owner label	Pass
Namespace without owner label	Fail

CI/CD Policy Validation

Developer Pull Request

↓

Render Kubernetes Manifests

↓

Kyverno CLI Policy Tests

↓

Image and Infrastructure Scans

↓

Security Approval

↓

Merge

↓

GitOps Deployment

↓

Admission Enforcement

Testing policies before deployment provides earlier feedback.

Policy Repository Structure

kyverno-policies/

├── policies/
│   ├── workload-security/
│   ├── identity/
│   ├── networking/
│   ├── supply-chain/
│   ├── governance/
│   └── operations/
│
├── environment-overlays/
│   ├── development/
│   ├── testing/
│   ├── production/
│   └── regulated/
│
├── tests/
│   ├── compliant/
│   └── non-compliant/
│
├── exceptions/
├── documentation/
└── README.md

GitOps Distribution

Kyverno policies can be deployed through GitOps.

Central Policy Repository

↓

Pull Request

↓

Security Review

↓

Automated Policy Tests

↓

GitOps Controller

↓

Amazon EKS Clusters

Benefits include:

Version control
Consistent policy deployment
Audit history
Rollback
Multi-cluster governance
Reduced manual changes

Multi-Cluster Policy Management

An enterprise may operate many EKS clusters across:

AWS accounts
Regions
Business units
Environments
Data classifications

A central policy model may use:

Enterprise Policy Baseline

↓

Risk-Based Overlays

├── Development
├── Production
├── Internet-Facing
├── Regulated
└── Critical Infrastructure

↓

GitOps Distribution

↓

Amazon EKS Clusters

Policy Tiers

Tier	Environment	Example Enforcement
Tier 1	Sandbox	Audit and warnings
Tier 2	Development	Baseline enforcement
Tier 3	Production	Restricted enforcement
Tier 4	Regulated	Enhanced verification and isolation

Policy tiers allow controls to match business risk.

Monitoring Kyverno

Kyverno participates in the Kubernetes admission path and must be monitored as critical platform infrastructure.

Important signals include:

Admission controller availability
Controller replica health
Admission request latency
Admission failures
Policy evaluation errors
PolicyReport failures
Background scan duration
Generate controller failures
Cleanup failures
Webhook certificate status
CPU and memory utilisation
Policy violations

Enterprise Monitoring Architecture

Kyverno Metrics and Events

↓

Prometheus

↓

Grafana

↓

Alertmanager

Meanwhile:

Kubernetes Audit Logs

↓

Amazon CloudWatch Logs

↓

Enterprise SIEM

↓

SOC and Platform Investigation

Kyverno Dashboard Metrics

Metric Area	Purpose
Admission requests	Measure policy-processing volume
Admission latency	Detect API performance impact
Policy results	Track pass, fail and error rates
Controller health	Confirm service availability
Policy changes	Detect unauthorised modifications
Background scans	Confirm compliance scanning
Generate failures	Detect missing generated resources
Image verification failures	Detect untrusted images
Policy exceptions	Track governance bypasses

Security Monitoring Use Cases

Kyverno events can detect:

Attempts to deploy privileged containers
Attempts to use unapproved images
Unsigned image deployments
Attempts to expose public services
Attempts to use HostPath
Attempts to omit required controls
Repeated policy bypass behaviour
Compromised deployment pipelines
Misconfigured automation identities

SIEM Correlation Example

Kyverno Denies Privileged Pod

+

Unusual AWS IAM Role Assumption

+

Repeated Kubernetes API Requests

↓

Potential Kubernetes Privilege-Escalation Attempt

High-risk policy violations should be treated as security signals, not only configuration errors.

Policy Modification Monitoring

Attackers with sufficient permissions may attempt to:

Delete Kyverno policies
Change Enforce to Audit
Add broad exclusions
Create PolicyExceptions
Modify webhook configurations
Scale Kyverno controllers to zero
Delete Kyverno resources

Monitor changes to:

Policies
ClusterPolicies
PolicyExceptions
Kyverno deployments
Kyverno Service Accounts
ClusterRoles
Webhook configurations

Protecting Kyverno

Kyverno should be protected through:

Restricted administrative access
Least-privilege RBAC
Dedicated namespace
Network controls
GitOps management
Admission-policy protection
Audit logging
Change alerts
Backup and recovery procedures

Only Approved Pipeline

↓

Can Modify Kyverno Policies

↓

All Changes Logged

↓

Security Team Alerted

Failure Behaviour

Kyverno depends on Kubernetes admission webhooks.

When the webhook cannot respond, Kubernetes must follow configured failure behaviour.

Fail Closed

Kyverno Unavailable

↓

Admission Request Rejected

Advantages:

Prevents policy bypass
Maintains security enforcement

Risks:

Deployments may stop
Cluster changes may fail
Emergency operations may be affected

Fail Open

Kyverno Unavailable

↓

Admission Request Allowed

Advantages:

Maintains deployment availability

Risks:

Insecure resources may be admitted
Creates an enforcement gap
Requires retrospective scanning
May violate compliance requirements

Choosing Failure Behaviour

Consider:

Policy criticality
Application availability
Cluster purpose
Regulatory obligations
Controller availability
Monitoring maturity
Emergency procedures
Recovery time

A policy that blocks privileged containers may require stricter failure behaviour than a policy requiring cost-centre labels.

High Availability

Production controls should include:

Multiple controller replicas
Pod anti-affinity
PodDisruptionBudgets
Resource requests and limits
Health probes
Monitoring and alerting
Controlled upgrades
Capacity planning
Certificate monitoring
Tested failure scenarios

Scaling Kyverno

Large EKS clusters may generate substantial admission volume.

Scaling considerations include:

Number of API requests
Number of policies
Policy complexity
Background scan frequency
Number of resources
Image verification latency
External registry performance
Generate-rule volume

Policy performance should be tested before enterprise rollout.

Policy Performance

Complex policies may increase admission latency.

Optimisation approaches include:

Narrow resource matching
Avoiding unnecessary wildcard scope
Limiting external dependencies
Reducing duplicated policies
Testing image verification latency
Monitoring rule execution
Separating high-volume workloads where appropriate

Upgrade Management

Kyverno upgrades should follow controlled change management.

Review Release Notes

↓

Review Kubernetes Compatibility

↓

Test Policy Behaviour

↓

Test CRD Changes

↓

Upgrade Non-Production

↓

Validate Admission and Reports

↓

Upgrade Production

↓

Monitor Closely

Do not treat a Kyverno upgrade as only a container-image change.

Policy definitions, CRDs, controllers and behaviour may evolve.

Policy Lifecycle

Security Requirement

↓

Policy Design

↓

Policy Development

↓

Automated Testing

↓

Audit Mode

↓

Remediation

↓

Enforcement

↓

Monitoring

↓

Periodic Review

↓

Policy Update or Retirement

Policy Ownership

Each policy should have a documented owner.

Policy Area	Possible Owner
Workload privileges	Cloud Security
Resource limits	Platform Engineering
Image verification	Supply Chain Security
Network exposure	Network Security
Service Accounts	Identity and Access Management
Required labels	Cloud Governance
Namespace automation	Platform Engineering
Retention and cleanup	Application Operations

Policy Documentation

Each policy should document:

Policy name
Security objective
Risk addressed
Affected resources
Enforcement mode
Owner
Exceptions
Framework mappings
Test cases
Rollout plan
Review date
Version history

Compliance Mapping

Kyverno policies can support requirements from:

CIS Kubernetes Benchmark
NSA Kubernetes Hardening Guidance
NIST controls
ISO/IEC 27001
PCI DSS
Internal cloud security standards
Software supply chain standards

Security Requirement	Kyverno Control
Containers must not be privileged	Validation policy
Workloads must run as non-root	Validation policy
Images must come from trusted sources	Registry validation
Images must be signed	Image verification
Namespaces require network isolation	Generate policy
Resources require ownership	Validation or mutation
Existing resources must be assessed	Background scanning and reports

Kyverno evidence supports compliance but does not automatically prove full compliance.

Common Security Risks

Policies Remain in Audit Mode

Policies identify violations but never block them.

Risk: Insecure resources continue to be deployed.

Control: Establish dates and criteria for moving critical policies to Enforce.

Overuse of Mutation

Security settings are silently added to resources.

Risk: Developers may not understand actual workload requirements, and GitOps drift may occur.

Control: Use mutation selectively and require explicit configuration for critical controls.

Broad Exceptions

Teams exclude entire namespaces or workload categories.

Risk: Policy enforcement becomes ineffective.

Control: Use narrow, approved and time-limited exceptions.

Inadequate Image Verification

A policy checks registry location but not image authenticity.

Risk: A compromised registry account may publish malicious images.

Control: Verify image signatures, provenance and attestations.

Controller Unavailability

Kyverno controllers fail or become overloaded.

Risk: Deployments may stop or policy enforcement may be bypassed.

Control: Use high availability, monitoring and tested failure behaviour.

Policy Drift

Clusters run different policy versions.

Risk: Enterprise standards are applied inconsistently.

Control: Use GitOps and central policy-version monitoring.

Policy Conflicts

Multiple policies mutate or validate the same field differently.

Risk: Unexpected results and failed deployments.

Control: Maintain central ownership, documentation and automated tests.

Missing Workload Coverage

Policies validate containers but ignore init or ephemeral containers.

Risk: Attackers or administrators may use unprotected container types.

Control: Test every applicable Pod container category.

No Runtime Detection

Kyverno validates configuration but does not detect all malicious runtime behaviour.

Risk: An application exploit may remain undetected after admission.

Control: Combine Kyverno with Falco, audit logging and SIEM monitoring.

Enterprise Implementation Strategy

Phase 1 — Define Policy Objectives

Review CIS, NSA and NIST guidance.
Identify enterprise Kubernetes risks.
Define mandatory controls.
Establish policy ownership.
Define environment tiers.
Create exception governance.
Select compliance metrics.

Phase 2 — Deploy Kyverno in Non-Production

Install Kyverno using Helm.
Use a dedicated namespace.
Verify all controllers.
Enable Prometheus metrics.
Validate webhook behaviour.
Test background scanning.
Review controller permissions.

Phase 3 — Build an Initial Policy Library

Start with high-value policies:

Deny privileged containers
Require non-root execution
Disable privilege escalation
Require resource limits
Require approved registries
Deny the latest tag
Require ownership labels
Restrict LoadBalancer Services
Restrict HostPath volumes
Require dedicated Service Accounts

Phase 4 — Introduce Namespace Automation

Generate default-deny Network Policies.
Generate ResourceQuotas.
Generate LimitRanges.
Apply ownership metadata.
Apply monitoring configuration.
Define secure namespace templates.

Phase 5 — Implement Supply Chain Security

Restrict approved registries.
Require immutable image references.
Sign container images.
Verify signatures.
Verify build attestations.
Monitor verification failures.
Protect signing identities.

Phase 6 — Test Policies

Use Kyverno CLI.
Test compliant manifests.
Test non-compliant manifests.
Test Pods and workload controllers.
Test init and ephemeral containers.
Test exclusions.
Test policy performance.
Integrate tests into CI/CD.

Phase 7 — Audit Existing Resources

Enable background scanning.
Review PolicyReports.
Assign violations to owners.
Identify false positives.
Remediate workloads.
Approve temporary exceptions.
Publish compliance dashboards.

Phase 8 — Enable Enforcement

Begin with critical production controls.
Use phased namespace rollout.
Communicate enforcement dates.
Monitor denied requests.
Validate application pipelines.
Maintain emergency procedures.
Confirm exception expiry.

Phase 9 — Scale Across the Enterprise

Store policies in Git.
Distribute policies through GitOps.
Define environment overlays.
Monitor policy versions.
Integrate PolicyReports with compliance systems.
Integrate high-risk violations with the SIEM.
Track enterprise coverage.

Phase 10 — Operate Continuously

Monitor Kyverno availability.
Review policy errors.
Track violations.
Review exceptions.
Test policy changes.
Upgrade Kyverno safely.
Review framework mappings.
Retire obsolete policies.
Conduct periodic effectiveness assessments.

Enterprise Best Practices

As a Cloud Security Engineer:

Use Kyverno as part of defence in depth.
Use ClusterPolicies for enterprise baselines.
Use namespaced Policies for delegated requirements.
Start policies in Audit mode.
Move mature critical policies to Enforce.
Deny privileged containers.
Require non-root execution.
Require restricted security contexts.
Enforce approved registries.
Verify image signatures and attestations.
Use immutable image digests.
Generate default namespace controls.
Use mutation selectively and transparently.
Store policies in Git.
Test policies using the Kyverno CLI.
Integrate policy tests into CI/CD.
Distribute policies using GitOps.
Monitor PolicyReports.
Integrate high-risk violations with the SIEM.
Protect Kyverno policies from unauthorised modification.
Use high availability for production controllers.
Monitor webhook latency and errors.
Use narrow, time-limited exceptions.
Test policy behaviour after upgrades.
Combine Kyverno with Pod Security Admission and runtime detection.

Real-World Scenario

A global financial organisation operates Amazon EKS clusters across multiple AWS accounts and Regions.

An internal assessment identifies:

Privileged containers
Applications running as root
Images pulled from public registries
Workloads using mutable tags
Missing resource limits
Public LoadBalancer Services
Namespaces without default-deny Network Policies
Inconsistent ownership labels
Unsigned production images

The organisation selects Kyverno as its Kubernetes-native policy engine.

The Cloud Security and Platform teams implement the following programme:

Install Kyverno using Helm in every EKS cluster.
Deploy ClusterPolicies in Audit mode.
Use PolicyReports to identify existing violations.
Assign remediation tasks to application owners.
Enforce non-root and non-privileged workload policies.
Restrict images to approved Amazon ECR registries.
Require signed images from approved CI/CD pipelines.
Generate default-deny Network Policies for new namespaces.
Mutate resources to add approved metadata and seccomp defaults.
Integrate Kyverno CLI tests into application pipelines.
Distribute policies using GitOps.
Forward high-risk denials to the enterprise SIEM.
Track exceptions through a formal approval and expiry process.
Publish compliance results through Grafana dashboards.

The organisation gains a consistent, automated and measurable security baseline across its EKS environment.

Key Takeaways

Kyverno is a Kubernetes-native policy engine.
Policies are primarily written using familiar Kubernetes YAML.
Policies can be namespaced or cluster-wide.
Validation policies audit or prevent insecure configurations.
Mutation policies apply approved defaults.
Generate policies automate supporting resource creation.
Image verification strengthens software supply chain security.
PolicyReports provide compliance visibility.
Background scanning identifies violations in existing resources.
Policies should be tested before enforcement.
Kyverno should be deployed as highly available infrastructure.
Exceptions must be narrow, approved and time-limited.
GitOps supports consistent multi-cluster policy management.
Kyverno complements RBAC, Pod Security Admission, Network Policies and runtime detection.

Knowledge Check

1. What is the primary benefit of Kyverno’s Kubernetes-native policy model?

Answer: Policies can be written and managed using familiar Kubernetes YAML, APIs and tools without requiring teams to learn a separate policy language for common use cases.

2. What is the difference between a Policy and a ClusterPolicy?

Answer: A Policy is namespaced and applies within one namespace, while a ClusterPolicy can apply across the entire cluster and to cluster-scoped resources.

3. What are the main Kyverno policy capabilities?

Answer:

Validate resources
Mutate resources
Generate resources
Verify images
Clean up resources
Report policy results

4. Why should validation policies begin in Audit mode?

Answer: Audit mode allows teams to identify violations, false positives and application impact without immediately blocking deployments.

5. How does Kyverno improve container supply chain security?

Answer: Kyverno can restrict approved registries, require immutable references and verify image signatures and attestations before workloads are admitted.

What’s Next?

In the next lesson, we will examine Kubernetes Admission Controllers and understand how built-in and dynamic admission controls evaluate, modify and approve API requests before resources are stored in the cluster.

➡️ Next Lesson: Lesson 08 — Admission Controllers