Kubernetes-native Security and Governance with Kyverno

Overview

In this blog, we will explore Kyverno, a powerful policy engine for Kubernetes that enables users to define policies as native Kubernetes resources. Kyverno helps validate, mutate, or generate resources dynamically, block non-compliant workloads through its admission controller, and log violations for compliance visibility and governance.

Pioneers in Cloud Consulting & Migration Services

Reduced infrastructural costs
Accelerated application deployment

Get Started

Introduction

Kyverno is an open-source policy engine designed specifically for Kubernetes, offering a policy-as-code approach to enforce custom rules within a cluster.

It functions as a dynamic admission controller, intercepting API server requests and evaluating them against defined policies. A key advantage of Kyverno is that policies are created using standard Kubernetes resources, eliminating the need to learn a separate policy language.

Kyverno Policy and Rule

devops

A Kyverno policy consists of several key components that define how it behaves and which resources it applies to:

rules: A policy must include at least one rule. Each rule specifies the logic to be enforced on Kubernetes resources.
background: When set to true, the policy is evaluated against existing resources in the cluster. It only applies to newly created or modified resources if set to false.
validationFailureAction: Determines the policy’s enforcement behavior. It can audit (log violations without blocking) or enforce (block non-compliant resources).

Each rule within a policy includes the following elements:

match: Specifies the criteria for selecting which resources the rule applies to (e.g., resource kinds, names, namespaces, labels, user roles, etc.).
exclude (optional): Defines conditions to exclude specific resources from policy evaluation.

The actions defined within a rule, mutate, validate, generate, and verifyImages, specify how Kyverno should interact with the targeted resources. Each action serves a unique purpose in enforcing policy behavior within the Kubernetes cluster.

mutate: Alters resource configurations before they are persisted.
validate: Ensures resource specifications meet required conditions.
generate: Automatically creates new Kubernetes resources when needed.
verifyImages: Validates the signatures of container images to ensure they are trusted.

Examples of Kyverno policy in action

Protecting Namespaces from Modification

Kyverno can be used to block changes to critical Kubernetes resources. Consider a scenario where we want to prevent updates or deletions of Namespace resources marked as protected using a label (protected=true).

This is useful for locking down system or environment-critical namespaces to avoid accidental or unauthorized changes.

update-deletion protection.yml

1	update-deletion protection.yml

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-updates-deletes
  annotations:
    policies.kyverno.io/title: Block Updates and Deletes
    policies.kyverno.io/category: webapp
    policies.kyverno.io/subject: RBAC
    policies.kyverno.io/description: >-
      This policy restricts updates and deletes to any Service resource that contains the label `protected=true`.
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: block-updates-deletes
    match:
      any:
      - resources:
          kinds:
          - Namespace
    validate:
      message: "This resource is protected and changes are not allowed."
      deny:
        conditions:
          any:
            - key: "{{request.operation || 'BACKGROUND'}}"
              operator: AnyIn
              value:
              - DELETE
              - UPDATE

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

annotations:

policies.kyverno.io/title: Block Updates and Deletes

policies.kyverno.io/category: webapp

policies.kyverno.io/subject: RBAC

policies.kyverno.io/description: >-

This policy restricts updates and deletes to any Service resource that contains the label `protected=true`.

spec:

validationFailureAction: enforce

background: false

rules:

- name: block-updates-deletes

match:

any:

- resources:

kinds:

- Namespace

validate:

message: "This resource is protected and changes are not allowed."

deny:

conditions:

any:

- key: "{{request.operation || 'BACKGROUND'}}"

operator: AnyIn

value:

- DELETE

- UPDATE

Outcome:
Once this policy is applied, attempts to delete or update a protected namespace will be blocked:

PS C:\WINDOWS\system32> kubectl delete ns webapp
Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

1 2	PS C:\WINDOWS\system32> kubectl delete ns webapp Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

2. Enforcing Node Affinity with nodeSelector

Kyverno policy can automatically enforce scheduling constraints by injecting a nodeSelector into a Pod specification. This is particularly useful when workloads must run on nodes with specific hardware, configurations, or placement.

The policy below ensures that any Pod created in the cluster gets scheduled only on nodes labeled with foo=bar and color=orange by mutating the Pod spec with the required nodeSelector.

Selector.yaml

1	Selector.yaml

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-nodeselector
  annotations:
    policies.kyverno.io/title: Add nodeSelector
    policies.kyverno.io/category: Sample
    policies.kyverno.io/subject: Pod
    policies.kyverno.io/minversion: 1.6.0
    policies.kyverno.io/description: >-
      The nodeSelector field uses labels to select the node on which a Pod can be scheduled.
      This can be useful when Pods have specific needs that only certain nodes in a cluster can provide.
      This policy adds the nodeSelector field to a Pod spec and configures it with labels `foo` and `color`.      
spec:
  rules:
  - name: add-nodeselector
    match:
      any:
      - resources:
          kinds:
          - Pod
    # Adds the `nodeSelector` field to any Pod with two labels.
    mutate:
      patchStrategicMerge:
        spec:
          nodeSelector:
            foo: bar
            color: orange

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

annotations:

policies.kyverno.io/title: Add nodeSelector

policies.kyverno.io/category: Sample

policies.kyverno.io/subject: Pod

policies.kyverno.io/minversion: 1.6.0

policies.kyverno.io/description: >-

The nodeSelector field uses labels to select the node on which a Pod can be scheduled.

This can be useful when Pods have specific needs that only certain nodes in a cluster can provide.

This policy adds the nodeSelector field to a Pod spec and configures it with labels `foo` and `color`.

spec:

rules:

- name: add-nodeselector

match:

any:

- resources:

kinds:

- Pod

# Adds the `nodeSelector` field to any Pod with two labels.

mutate:

patchStrategicMerge:

spec:

nodeSelector:

foo: bar

color: orange

Before applying the policy, we need to label the target node to match the nodeSelector:

PS C:\WINDOWS\system32> kubectl label nodes minikube foo=bar color=orange
node/minikube labeled

1 2	PS C:\WINDOWS\system32> kubectl label nodes minikube foo=bar color=orange node/minikube labeled

Then, create a simple Pod manifest:

Pod_selector.yml

1	Pod_selector.yml

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  labels:
    foo: bar
    color: orange
spec:
  containers:
  - name: nginx-container
    image: nginx:latest

apiVersion: v1

kind: Pod

metadata:

labels:

foo: bar

color: orange

spec:

containers:

- name: nginx-container

image: nginx:latest

Once applied, Kyverno mutates the Pod spec by injecting the required nodeSelector, ensuring the Pod is scheduled only on matching nodes.

Output:

PS C:\WINDOWS\system32> kubectl get pod example-pod -o wide
NAME          READY   STATUS    RESTARTS   AGE    IP            NODE       NOMINATED NODE   READINESS GATES
example-pod   1/1     Running   0          4m6s   10.244.1.71   minikube   <none>           <none>

PS C:\WINDOWS\system32> kubectl get pod example-pod -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES

example-pod 1/1 Running 0 4m6s 10.244.1.71 minikube <none> <none>

As seen, the Pod is scheduled on the minikube node that matches the specified labels, validating that the policy is successfully applied.

Benefits

Enforce security rules to prevent deployment of non-compliant or unsafe resources.
Streamline operations by enabling real-time resource modifications
Allow flexible policy modes, audit (monitor only), or enforce (block violations)
Provide an easier approach to writing policies, especially compared to Gatekeeper

Conclusion

Kyverno brings Kubernetes-native simplicity to policy enforcement, allowing teams to secure, validate, and automate workloads. With audit support and enforce modes, it offers flexibility for both testing and production use. While it greatly improves governance, ensuring high availability is key to avoiding downtime.

Drop a query if you have any questions regarding Kyverno and we will get back to you quickly.

Empowering organizations to become ‘data driven’ enterprises with our Cloud experts.

Reduced infrastructure costs
Timely data-driven decisions

Get Started

About CloudThat

CloudThat is an award-winning company and the first in India to offer cloud training and consulting services worldwide. As a Microsoft Solutions Partner, AWS Advanced Tier Training Partner, and Google Cloud Platform Partner, CloudThat has empowered over 850,000 professionals through 600+ cloud certifications winning global recognition for its training excellence including 20 MCT Trainers in Microsoft’s Global Top 100 and an impressive 12 awards in the last 8 years. CloudThat specializes in Cloud Migration, Data Platforms, DevOps, IoT, and cutting-edge technologies like Gen AI & AI/ML. It has delivered over 500 consulting projects for 250+ organizations in 30+ countries as it continues to empower professionals and enterprises to thrive in the digital-first world.

FAQs

1. Can Kyverno be used alongside Gatekeeper?

ANS: – Yes. Kyverno can run alongside Gatekeeper, but it is important to carefully design policies to avoid overlaps or conflicts that might result in unexpected behavior.

2. What happens if Kyverno pods become unavailable?

ANS: – If Kyverno is down, Kubernetes may block the creation or modification of new resources, depending on admission controller settings. Running Kyverno in high availability mode helps prevent this issue.

3. Can policies be tested before enforcing them in production?

ANS: – Absolutely. We can use the audit mode to record and review policy violations without actually blocking non-compliant resources, making it easier to test and fine-tune policies before moving to enforce mode.

WRITTEN BY Abhilasha D

Abhilasha D works as a Research Associate-DevOps at CloudThat. She is focused on gaining knowledge of the cloud environment and DevOps tools. Abhilasha is interested in learning and researching emerging technologies and is skilled in dealing with problems in a resourceful manner.