As the system grew, I found myself working with Go microservices, GraphQL, gRPC, Kubernetes, OpenTofu, GitOps, observability, cloud security, and local cloud emulation.

This article is a look at how those technologies come together to power StudEd and, more importantly, what I learned while building it.

What is StudEd?

StudEd is a cloud-native educational platform designed to provide a modern learning experience while keeping the underlying system scalable and maintainable.

Instead of building everything inside one large backend, StudEd is divided into independent services, each responsible for a specific part of the platform.

The architecture was designed around an important idea:

The application should be easy to develop, easy to deploy, and easy to observe as it grows.

That naturally led me toward a microservices architecture.

The Architecture

At a high level, the system looks like this:

Clients → Edge Layer → API Gateway → Microservices → Data Layer

Around that core flow sits the platform infrastructure responsible for deployment, security, secrets, infrastructure provisioning, and observability.

The diagram above shows how the different layers connect and how requests move through the platform.

Go Microservices at the Core

The backend is built with Go (Golang) and divided into domain-focused microservices.

Some of the main services include:

• API Gateway — provides the main GraphQL interface for clients.
• Auth Service — handles authentication, tokens, and permissions.
• Course Service — manages courses, curriculum, and learning content.
• Progress Service — tracks student progress and completion.
• Gamification Service — handles XP, achievements, and leaderboards.
• AI Service — provides intelligent learning and content-related features.
• Payment Service — manages payment workflows.
• Notification Service — handles application notifications.
• Upload Service — manages media and document uploads.

Each service has its own responsibility rather than everything being handled by one large codebase.

This makes the platform easier to evolve because individual services can be developed and deployed independently.

GraphQL for the Client, gRPC Between Services

One of the architectural decisions I found particularly interesting was using two different communication patterns.

For the frontend, StudEd exposes a unified GraphQL API.

For communication between backend services, it uses gRPC with Protocol Buffers.

So the flow is essentially:

Frontend → GraphQL → API Gateway → gRPC → Microservices

GraphQL gives the client a flexible API, while gRPC provides strongly typed and efficient communication between internal services.

Using Protocol Buffers also gives the services explicit contracts, making the boundaries between them much clearer.

Choosing the Right Data Store

Not everything belongs in the same database.

StudEd uses different technologies for different workloads.

PostgreSQL

Neon Serverless PostgreSQL is used for relational application data that needs strong transactional consistency.

Redis

Redis handles fast-changing state such as caching, token-related operations, sessions, and rate limiting.

Elasticsearch

Elasticsearch powers advanced search across courses, instructors, lessons, and other content, including support for fuzzy and internationalized text search.

This approach lets each component use a storage system that fits its job instead of forcing the entire platform into one database.

Kubernetes and Platform Engineering

Once you have multiple services, deployment becomes a problem of its own.

StudEd runs on Kubernetes, with the production architecture built around Google Kubernetes Engine (GKE).

The platform also uses several tools around Kubernetes:

ArgoCD

ArgoCD provides the GitOps workflow.

Instead of manually changing cluster resources, the desired state lives in Git and ArgoCD continuously reconciles the cluster with that state.

Kyverno

Kyverno is used to enforce Kubernetes policies such as secure container configurations, immutable image references, and resource limits.

External Secrets Operator

Secrets are kept outside application manifests and synchronized into Kubernetes through External Secrets Operator and Google Secret Manager.

Network Policies

The cluster follows a default-deny, zero-trust approach, controlling which services are allowed to communicate with each other and where workloads can send traffic.

This is where StudEd moved from simply being a backend project into something much closer to a real platform engineering environment.

OpenTofu: Infrastructure as Code

I didn't want the infrastructure to depend on manual setup.

That is where OpenTofu comes in.

The infrastructure is defined declaratively so networking, compute, security, storage, and other cloud resources can be reproduced consistently.

The same infrastructure approach can also target local cloud emulation environments during development.

That makes the infrastructure part of the project itself rather than something that exists separately from the code.

Floci: Building the Cloud Locally

One of the tools I particularly wanted to experiment with was Floci.

Cloud development can get expensive and slow when every small test requires real cloud resources.

Floci gives the project local emulation for cloud services such as:

• Cloud Storage
• Secret Manager
• Pub/Sub

This means I can test cloud-dependent functionality locally without constantly deploying to a real environment.

For me, this became especially useful for the developer inner loop: build locally, test locally, then move toward the actual cloud environment.

Containers Everywhere

StudEd is containerized using Docker and Podman.

The services use multi-stage builds so development dependencies and compiler tooling don't have to end up inside the final runtime image.

This keeps the containers smaller and reduces unnecessary components in production images.

Observability Is Not an Afterthought

When you have a single application, finding a problem can be relatively straightforward.

With multiple microservices, it gets much harder.

A request can travel through the API Gateway, several services, a database, Redis, and external systems before the user sees a response.

That is why StudEd includes a dedicated observability stack built around:

OpenTelemetry + Prometheus + Grafana + Tempo

OpenTelemetry provides distributed tracing across services.

Prometheus collects application and infrastructure metrics.

Grafana turns those metrics into operational dashboards.

Tempo stores and visualizes distributed traces.

Together, they make it possible to move from:

"Something is slow."

to:

"This specific service or database operation caused the slowdown."

The Frontend and Delivery Pipeline

On the client side, StudEd uses TypeScript, Vite, and Bun, with the frontend deployed through Cloudflare Pages.

The delivery pipeline is built around GitHub Actions, container registries, automated validation, and GitOps deployment.

This means the development workflow is not simply:

write code → manually deploy

Instead, code moves through a controlled pipeline before reaching the running environment.

The Technology Stack

The important part isn't simply the number of technologies.

It's how they work together to solve different problems across the platform.

What I Learned Building StudEd

StudEd taught me that building a distributed system is very different from simply building an application.

Writing a microservice is one thing.

Deciding where that service belongs, how it communicates, how it is deployed, how its secrets are managed, how it is observed, and how developers can reproduce its environment locally is a completely different challenge.

The biggest lesson for me was that technologies such as Kubernetes, OpenTofu, ArgoCD, OpenTelemetry, and Floci aren't isolated tools.

They become useful when they work together as part of a platform.

And that is the part of StudEd I enjoyed the most: taking an educational product idea and using it as a practical playground for learning cloud-native engineering and platform engineering.

Final Thoughts

StudEd is still evolving, but the architecture has already given me hands-on experience with many of the ideas behind modern cloud-native systems.

From Go microservices and gRPC to Kubernetes, GitOps, Infrastructure as Code, local cloud emulation, and distributed observability, the project has become much more than an educational application.

It has become a way for me to understand what happens behind the application.

And honestly, that's where things get interesting.

For simple web applications, this boundary was sufficient. But as modern enterprise software evolved to demand complex multi-attribute filtering, nested JSON search payloads, dynamic analytics aggregation, and fine-grained pagination, GET began breaking under its own constraints — while abusing POST created architectural anti-patterns.

Enter the HTTP QUERY method (RFC 10008): a standardized HTTP verb designed explicitly to execute safe, idempotent, and cacheable queries with rich request bodies.

The Dilemma: Why GET and POST Fail for Complex Search

The Problem with GET

By HTTP specification, GET requests carry their intent inside the Request-URI and query parameters:

GET /api/v1/products?category=electronics&page=2&sort=price

This works cleanly for simple lookups. However, when building complex enterprise search engines (such as product filters, log aggregators, or telemetry dashboards), query strings become chaotic:

GET /api/v1/products?filter%5Bcategory%5D%5B%5D=electronics&filter%5Bcategory%5D%5B%5D=gaming&filter%5Bprice%5D%5Bmin%5D=100&filter%5Bprice%5D%5Bmax%5D=1000&sort%5B0%5D%5Bfield%5D=rating&sort%5B0%5D%5Bdirection%5D=desc

This approach presents severe production risks:

• URL Truncation: Browsers, reverse proxies (Nginx, HAProxy), and Cloudflare edge nodes enforce strict URL length limits (often 2KB–8KB).
• Encoding Hell: Nested arrays and objects require heavy URL encoding, destroying readability and developer experience.
• Security & Privacy Leakage: Search terms, tokens, or PII passed in URL parameters are routinely recorded in plain text inside access logs, CDN logs, and browser histories.

The Problem with POST as a Search Fallback

To circumvent URL limits, developers started wrapping search queries inside POST bodies:

POST /api/v1/products/search
Content-Type: application/json

{
  "categories": ["electronics", "gaming"],
  "price": { "min": 100, "max": 1000 },
  "sort": [{ "field": "rating", "direction": "desc" }]
}

While this solves payload size issues, it violates HTTP semantics:

• POST is Non-Safe and Non-Idempotent: HTTP clients and proxies assume POST modifies server-side state. Dropped connections cannot be safely retried automatically by resilient network clients.
• Broken Caching: Edge CDNs, HTTP caches, and browser caches ignore POST responses by default.
• Semantic Anti-Pattern: Creating endpoint hacks like POST /products/search or POST /products/filter misrepresents a pure read operation as a mutation.

The Solution: HTTP QUERY (RFC 10008)

Published as a Proposed Standard by the IETF HTTP Working Group (authored by Julian Reschke, James M. Snell, and Mike Bishop), RFC 10008 introduces the QUERY method.

QUERY combines the safety and idempotency of GET with the structured payload capabilities of POST:

QUERY /api/v1/products HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json

{
  "categories": ["electronics", "gaming"],
  "price": { "min": 100, "max": 1000 },
  "features": ["Bluetooth", "5G", "OLED"],
  "sort": [{ "field": "rating", "direction": "desc" }]
}

Protocol Comparison Matrix

Protocol Semantics & Header Standards

1. Mandatory Content-Type: The server requires a valid Content-Type header (e.g., application/json, application/graphql, or application/sql). If missing, the server returns 400 Bad Request or 415 Unsupported Media Type.
2. Content-Location Header Response: Servers can return a Content-Location header in the response pointing to a persistent resource URL.
3. HTTP Status Codes:
   • 200 OK: Query executed successfully.
   • 400 Bad Request: Missing or malformed query payload.
   • 415 Unsupported Media Type: Query format not recognized by backend.
   • 422 Unprocessable Entity: Query syntax valid, but logical parameters invalid.

Ecosystem Support & Practical Implementation

Client & Framework Adoption

Language ecosystems and frameworks are rolling out native QUERY support:

• .NET 10 (LTS): Native support via HttpMethod.Query in HttpClient and HttpMethods.IsQuery in ASP.NET Core Kestrel.
• Node.js & Go: HTTP client drivers allow registering QUERY as a custom verb across backend microservices.
• API Gateways & CDNs: Cloudflare and Akamai are building edge caching rules for RFC 10008 QUERY responses.

Strategic Adoption Strategy

1. Service-to-Service (gRPC / Internal REST Microservices): Adopt QUERY for microservices communicating internally where both client and server are controlled by your platform team.
2. Public REST APIs: Provide QUERY endpoints while offering a POST /search fallback for legacy web clients until browser fetch() APIs universally expose the verb.
3. Platform Engineering & Monitoring: Use QUERY for log aggregation, Elasticsearch queries, metrics telemetry, and complex reporting endpoints.

Conclusion

The HTTP QUERY method represents a crucial evolution in Web and Platform Engineering. By granting developers a safe, idempotent method equipped with a structured request body, RFC 10008 finally solves a two-decade-old API design trade-off.

The result of our 24-hour sprint was Turboship, an AI-powered Internal Developer Platform (IDP) control plane that achieved 2nd Place (n8n Track) and 14th Place Overall out of 100+ competing teams.

The Problem We Set Out to Solve

Deploying containerized microservices to cloud providers like AWS ECS or Azure Container Apps usually requires writing verbose Infrastructure-as-Code (Terraform, Bicep, CDK), configuring IAM policies, managing secrets, and running security vulnerability scans manually.

For small teams and fast-moving developers, this overhead slows down ship velocity.

# Traditional manual deployment flow
docker build -t username/app:latest .
docker push username/app:latest
aws ecs create-cluster --cluster-name production
aws ecs register-task-definition --cli-input-json file://task-def.json
aws ecs create-service --cluster-name production --service-name app-service

The Turboship Architecture

Turboship automates the entire control plane using an agentic AI orchestration pipeline. Users simply submit a public Docker Hub image URL, and Turboship's AI workflow takes over.

Architecture Highlights:

1. Runtime Requirements Analysis: GPT-5.5 inspects image metadata and recommends optimal vCPU/RAM allocations.
2. Automated Vulnerability Scanning: Integrated Trivy vulnerability scanner checks image layers for CVEs before deployment.
3. Multi-Cloud Provisioning: Executes secure AWS SigV4 signed requests to deploy directly to AWS ECS Fargate and Azure Container Apps.
4. Human-in-the-Loop Safeguards: Displays proposed infrastructure costs and security findings for developer approval before executing cloud mutations.

Tech Stack & Key Takeaways

• Frontend Control Plane: Next.js 15 & Tailwind CSS with WebGL status monitors.
• Agentic Orchestration Engine: n8n workflows integrated with OpenAI GPT-5.5.
• Security & Vulnerability Analysis: Trivy scanner CLI & AWS SigV4 request signatures.
• Cloud Targets: AWS ECS Fargate & Azure Container Apps.

Building Turboship in 24 hours proved the power of coupling AI agents with structured workflow orchestration engines like n8n.

Building a modern developer portfolio should never be a generic template exercise. It is a flagship showcase of technical discipline, design aesthetics, performance optimization, and creative engineering.

In this article, I break down the engineering decisions, performance benchmarks, and interactive systems behind my personal portfolio—built with React 19, TanStack Router, GSAP ScrollTrigger, Bun runtime, and Tailwind CSS v4.

1. High-Performance Architecture Overview

2. 100% Type-Safe Routing & Intent Preloading

Traditional string-based routing (/blog/my-post) is prone to broken link bugs and unhandled parameters. Using TanStack Router, every route path, search parameter, and loader function is generated into static TypeScript types (routeTree.gen.ts).

Key Performance Benefits:

• Intent Preloading: Hovering a navigation link or project card triggers async code-splitting downloads in the background before the user even clicks.
• Zero Layout Shift: Route loaders resolve data prior to view transition, eliminating loading spinner flashes.

import { createFileRoute } from '@tanstack/react-router';

export const Route = createFileRoute('/blog/$slug')({
  component: BlogPostPage,
});

function BlogPostPage() {
  const { slug } = Route.useParams();
  return <BlogPostView slug={slug} />;
}

3. GSAP Physics & Interactive <BounceCards /> Engine

Rather than relying on basic CSS transitions, complex interactive sections (such as Volunteering experience cards) utilize GSAP (GreenSock) animation contexts combined with spring physics (elastic.out(1, 0.7)).

Sibling Push Hover Mechanics

When hovering over an event photo card inside the ReactBits <BounceCards /> component:

1. The hovered card smoothly rotates upright (rotate(0deg)), scales up (scale(1.08)), and elevates z-index (z-30).
2. Sibling cards push outward dynamically based on index distance (offsetX = i < hoveredIdx ? -55px : 55px) with staggered spring easing (back.out(1.4)).
3. Natural Aspect Ratio: Configured to preserve native landscape ratios (aspect-[16/10]), ensuring zero photo cropping for event galleries.

4. Premium Dark Black, Silver & Obsidian Design System

The design follows strict premium aesthetic guidelines:

• Color Palette: Obsidian black backgrounds (bg-black/90), subtle silver borders (border-neutral-800/80), and high-contrast typography.
• Glassmorphism: Backdrop blur filters (backdrop-blur-xl), subtle radial glows, and white/silver borders (hover:border-neutral-700).
• Typography Hierarchy: Main hero titles leverage Instrument Serif (font-serif), while technical subtopics, tags, and code blocks use bold high-contrast Sans-Serif and Monospace.

5. Zero-Asset Audio Synthesis (Web Audio API)

To maintain a lightweight build footprint, all interactive UI sounds (button clicks, hover ticks, level-up chimes) are generated programmatically using Web Audio API oscillators — 0 KB audio files downloaded over the network.

// Zero-Asset Button Click Sound Synthesizer
export function playClickSound() {
  const ctx = new (window.AudioContext || (window as any).webkitAudioContext)();
  const osc = ctx.createOscillator();
  const gain = ctx.createGain();
  
  osc.type = 'sine';
  osc.frequency.setValueAtTime(800, ctx.currentTime);
  osc.frequency.exponentialRampToValueAtTime(200, ctx.currentTime + 0.05);
  
  gain.gain.setValueAtTime(0.08, ctx.currentTime);
  gain.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime + 0.05);
  
  osc.connect(gain);
  gain.connect(ctx.destination);
  
  osc.start();
  osc.stop(ctx.currentTime + 0.05);
}

6. Performance Benchmarks & Build Metrics

Conclusion

This portfolio demonstrates that client-side React applications, when architected with type-safe routing, physics-driven animations, disciplined design tokens, and fast build tools, can deliver desktop-class responsiveness and aesthetic perfection.

You can deploy a container that runs as the root user, giving it administrator-level access to the machine it runs on. You can run a pod with no CPU or memory limits, letting it consume an entire node and slow down every other workload. You can create namespaces with no labels, making your cluster impossible to manage at scale.

Kubernetes accepts all of this without a single warning. That is not a bug. Kubernetes is built to be flexible. But that flexibility means the responsibility of setting boundaries falls entirely on you.

That is what a policy engine does. And Kyverno is the simplest one built for Kubernetes today.

This guide covers what Kyverno is, why it is the right choice for most teams, how it works inside Kubernetes, and how to write your first three policies from scratch. Every command is verified against the official Kyverno documentation (v1.17.1, released February 2026).

What Is Kyverno?

Kyverno is a policy engine built specifically for Kubernetes. The name comes from the Greek word for “govern.”

Its defining feature: Kyverno policies are Kubernetes resources written in plain YAML. You do not need to learn a new language or a new syntax. If you can read a Deployment manifest, you can read a Kyverno policy.

Kyverno is a CNCF Incubating project under the Cloud Native Computing Foundation (CNCF), the same organization that oversees Kubernetes, Prometheus, and Argo.

It does three things that cover the vast majority of real-world policy needs:

• Validate — check a resource against your rules, and reject it if it does not comply
• Mutate — automatically add or correct fields in a resource before it is stored
• Generate — automatically create a new resource when another resource is created

Each of these is covered with a working example below.

Official documentation: kyverno.io/docs

Why Kyverno and Not OPA Gatekeeper?

If you have researched Kubernetes policy engines, you have likely seen two names: Kyverno and Open Policy Agent (OPA) Gatekeeper. Both are CNCF projects. Both solve the same core problem. The difference is how you write policies.

OPA Gatekeeper uses a language called Rego, a purpose-built query language for policy logic. It is powerful and works across platforms beyond Kubernetes. But Rego has a genuine learning curve, and most platform teams need dedicated time to become productive with it.

Kyverno uses YAML, the same format your team already uses for everything in the cluster.

For a team working primarily in Kubernetes, Kyverno is the faster choice to get running and the easier one to maintain. Your team can read, review, and update policies without learning anything new. That matters when a policy needs to change quickly.

OPA Gatekeeper is the better choice if you need policy enforcement that spans multiple platforms beyond Kubernetes. If your scope is Kubernetes, Kyverno is the more practical option.

How Kyverno Works

The short version: Kyverno intercepts your kubectl apply before the resource is saved. If it breaks a rule, it never gets created.

Every time you run kubectl apply, the request travels to the Kubernetes API server. Before that request is written to the cluster's database (etcd), the API server passes it through admission controllers — a chain of plugins that can inspect, modify, or reject the request.

Kyverno registers itself as two of these:

1. A MutatingAdmissionWebhook — receives the request first and can change it. This is how mutation works.
2. A ValidatingAdmissionWebhook — receives the request after mutation and can approve or reject it. This is how validation works.

This happens before the resource exists. A pod that violates a policy is not created and then flagged — it is never created at all. The error comes back to your terminal immediately, with the exact message you wrote in your policy.

Installing Kyverno

Helm is the recommended installation method. Run these three commands:

# Step 1 — Add the Kyverno Helm repository
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

# Step 2 - Install Kyverno into its own namespace
helm install kyverno kyverno/kyverno \
  -n kyverno \
  --create-namespace

# Step 3 - Verify the installation
kubectl get pods -n kyverno

You should see four pods running:

kyverno-admission-controller-xxx      1/1   Running
kyverno-background-controller-xxx     1/1   Running
kyverno-cleanup-controller-xxx        1/1   Running
kyverno-reports-controller-xxx        1/1   Running

Important: Always install Kyverno in a dedicated namespace. Never place it in kube-system or alongside other workloads. Kyverno automatically excludes its own namespace from policy enforcement, any workload sharing that namespace is excluded too.

Full installation guide: kyverno.io/docs/installation/methods

ClusterPolicy vs Policy

Before writing a policy, you need to choose its scope.

Policies can be defined as cluster-wide resources using ClusterPolicy or as namespaced resources using Policy. Namespaced policies will only apply to resources within the namespace in which they are defined, while cluster-wide policies apply to matching resources across all namespaces. Otherwise there is no difference between the two types.

Use ClusterPolicy for rules that every team must follow, like no root containers or required labels.

Use Policy when a single team needs their own rules inside their own namespace.

All examples in this guide use ClusterPolicy.

Note on ClusterPolicy: Kyverno 1.17 officially marks ClusterPolicy as deprecated. While it remains fully functional in this release, the Kyverno team recommends new policies be based on the new CEL APIs going forward. However, ClusterPolicy is still the right starting point for learning Kyverno. Once you understand the basics here, you can explore the newer ValidatingPolicy and MutatingPolicy types in the official docs.

Validate Policies: Check Resources Before They Are Created

A validate policy checks whether a resource follows your rules. If it does not, Kubernetes rejects the request and shows your error message to the developer.

Two modes: Audit and Enforce

Every validate rule has a failureAction field.

• Audit — the resource is allowed through, but the violation is recorded in a Policy Report. Nothing breaks. You can see what is non-compliant before you start blocking anything.
• Enforce — the resource is rejected immediately. The developer sees your error message in their terminal.

Start with Audit. Then switch to Enforce once you are confident.

This is the most important habit when using Kyverno. If you apply a new policy in Enforce mode without checking your cluster first, you may accidentally block applications that are already running.

Example 1: Require a Label on Every Pod

Labels are how Kubernetes resources find each other. A Service finds its Pods using labels. A NetworkPolicy selects targets using labels. Without consistent labels, your cluster becomes harder to manage.

The failureAction tells Kyverno if the resource being validated should be allowed but reported (Audit) or blocked (Enforce). The pattern object defines what pattern will be checked in the resource.

This policy checks that every Pod has an app.kubernetes.io/name label:

# require-labels.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  rules:
    - name: check-for-labels
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Audit
        message: "Every Pod must have an 'app.kubernetes.io/name' label."
        pattern:
          metadata:
            labels:
              app.kubernetes.io/name: "?*"

Apply it:

kubectl apply -f require-labels.yaml

What the fields mean:

• match.any — which resources this rule applies to. Here, all Pods.
• validate.failureAction — set to Audit so violations are logged but not blocked.
• validate.message — the error message shown to the developer when the rule fails.
• validate.pattern — the shape the resource must match. "?*" means any non-empty string.

Test with a pod that has no label:

kubectl run test-pod --image=nginx:1.27 --restart=Never

In Audit mode the pod is created. Check the violation report:

kubectl get policyreport -A

Now change failureAction to Enforce in the YAML, apply it again, and try the same command. The pod is rejected immediately.

A pod that passes the policy:

kubectl run labeled-pod \
  --image=nginx:1.27 \
  --restart=Never \
  --labels="app.kubernetes.io/name=web"

Example 2: Block Containers That Run as Root

In Linux, user ID 0 is root. A container running as root has full administrator access on the host machine it runs on. If that container is compromised, the attacker can cause much more damage than they should be able to.

This policy blocks any Pod that does not explicitly set runAsNonRoot: true:

# disallow-root.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root
spec:
  rules:
    - name: check-runasnonroot
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Containers must not run as root. Set spec.securityContext.runAsNonRoot: true."
        pattern:
          spec:
            securityContext:
              runAsNonRoot: true

Apply and test:

kubectl apply -f disallow-root.yaml

# This will be rejected
kubectl run root-pod --image=nginx:1.27 --restart=Never

# This will be allowed
kubectl run safe-pod \
  --image=nginx:1.27 \
  --restart=Never \
  --overrides='{"spec":{"securityContext":{"runAsNonRoot":true,"runAsUser":1000}}}'

Example 3: Block the latest Image Tag

The latest tag means "whatever the registry currently considers latest." It changes without notice, which makes deployments unpredictable and rollbacks unreliable. This policy blocks any container using the latest tag:

# disallow-latest-tag.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  rules:
    - name: check-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "The 'latest' tag is not allowed. Use an explicit version tag like nginx:1.27."
        pattern:
          spec:
            containers:
              - image: "!*:latest"

Apply and test:

kubectl apply -f disallow-latest-tag.yaml

# Rejected
kubectl run bad-pod --image=nginx:latest --restart=Never

# Allowed
kubectl run good-pod --image=nginx:1.27 --restart=Never

Browse hundreds of ready-to-use policies: kyverno.io/policies

Mutate Policies: Fix Resources Automatically

A mutate policy changes a resource before it is saved. The developer submits it, Kyverno adjusts it in the background, and the corrected version is what gets stored.

This is friendlier than validation. Instead of rejecting a pod and sending a developer back to fix their YAML, Kyverno quietly adds what is missing and lets the work continue.

The noisy neighbor problem

One of the most common production issues in Kubernetes is the “noisy neighbor.” A pod with no resource limits gradually takes all the CPU or memory on a node, slowing down every other application sharing that machine. The developer did not do this deliberately. They just forgot to set limits.

A validate policy would reject their pod. A mutate policy adds safe defaults and lets the pod through.

# add-default-resource-limits.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-resource-limits
spec:
  rules:
    - name: set-resource-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - (name): "*"
                resources:
                  limits:
                    +(memory): "256Mi"
                    +(cpu): "500m"
                  requests:
                    +(memory): "128Mi"
                    +(cpu): "250m"

Apply and check the result:

kubectl apply -f add-default-resource-limits.yaml

# Create a pod with no resource limits
kubectl run test-pod --image=nginx:1.27 --restart=Never

# See what Kyverno added automatically
kubectl get pod test-pod -o jsonpath='{.spec.containers[0].resources}'

Two pieces of Kyverno syntax used here:

• (name): "*" — the parentheses make this a conditional anchor. It matches every container by name and applies the mutation to each one.
• +(memory) — the plus sign means "only add this field if it does not already exist." Pods that already have resource limits set by the developer are not changed.

Generate Policies: Create Resources Automatically

A generate policy creates a new Kubernetes resource automatically when you create another resource. It turns manual steps into automatic ones.

Example: Create a NetworkPolicy for every new Namespace

The safest default for network traffic between pods is to block everything and only allow what you explicitly permit. But creating a NetworkPolicy in every new namespace is easy to forget.

This policy does it automatically:

# generate-default-networkpolicy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-default-networkpolicy
spec:
  rules:
    - name: create-deny-all-networkpolicy
      match:
        any:
          - resources:
              kinds:
                - Namespace
      generate:
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: deny-all-ingress
        namespace: "{{request.object.metadata.name}}"
        synchronize: true
        data:
          spec:
            podSelector: {}
            policyTypes:
              - Ingress

Apply and test:

kubectl apply -f generate-default-networkpolicy.yaml

# Create a new namespace
kubectl create namespace my-team

# Kyverno created this automatically
kubectl get networkpolicy -n my-team

The synchronize: true field means if the generated resource is ever deleted manually, Kyverno will recreate it. It is an ongoing guarantee, not a one-time action.

Testing Policies Before You Apply Them

The Kyverno CLI lets you test a policy against a YAML file on your own machine. Nothing touches the cluster. This is the safest way to develop policies and the foundation of a “shift left” approach, catching policy violations on your laptop or in a CI pipeline, before anything reaches the cluster.

Install the CLI

macOS:

brew install kyverno

Linux (via Krew):

kubectl krew install kyverno

Check it is working:

kubectl kyverno version

CLI documentation: kyverno.io/docs/kyverno-cli

Test a validation policy

Create a test pod manifest:

# test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: nginx
      image: nginx:1.27

Run the test:

kubectl kyverno apply require-labels.yaml --resource test-pod.yaml

You will see:

policy require-labels -> resource default/Pod/test-pod
  FAILED: Every Pod must have an 'app.kubernetes.io/name' label.
pass: 0, fail: 1, warn: 0, error: 0, skip: 0

Test a mutation policy

kubectl kyverno apply add-default-resource-limits.yaml --resource test-pod.yaml

This prints the mutated resource so you can see exactly what Kyverno would add.

Best Practices

• Start with Audit, move to Enforce. Apply every new policy in Audit mode first. Check the policy report. Fix non-compliant resources. Then switch to Enforce.
• Use +(field) for mutation defaults. The plus sign only fills a field when it is absent. Without it, your mutation will overwrite values that developers have already set deliberately.
• Store policies in Git. Treat your ClusterPolicy files like application code. Review changes in pull requests. Apply them through a GitOps pipeline so your cluster’s rules are always in a known, tracked state.
• Test with the CLI in CI. Add kubectl kyverno apply to your pipeline after generating manifests. If any manifest fails a policy, the pipeline stops. Policy violations are caught in code review, not after deployment.

Summary

Kubernetes is flexible by design. Kyverno adds the rules your team needs, without requiring a new language.

The three policy types cover most real-world needs:

• Validate rejects resources that break your rules before they are ever created
• Mutate quietly fills in missing fields so developers do not have to remember everything
• Generate replaces manual steps with automatic guarantees

The safest way to roll out any new policy is: write it, test it with the CLI, apply it in Audit mode, check the policy report, fix any issues, then switch to Enforce.

Start with the require-labels example. It is simple, it immediately improves how your cluster is managed, and it teaches you the full Kyverno YAML structure in one small policy.

Policy library: kyverno.io/policies

If this guide helped you get Kyverno running, consider sharing it with your team. If you are curious about the next step, whether writing policies for multi-environment clusters or exploring the new CEL-based policy types in Kyverno, let me know in the comments. I will cover it in the next article.

References

• Kyverno documentation: kyverno.io/docs/introduction/
• How Kyverno works: kyverno.io/docs/introduction/how-kyverno-works
• Quick start guide: kyverno.io/docs/introduction/quick-start
• Validate rules reference: kyverno.io/docs/policy-types/cluster-policy/validate
• Mutate rules reference: kyverno.io/docs/policy-types/cluster-policy/mutate
• Generate rules reference: kyverno.io/docs/policy-types/cluster-policy/generate
• Installation methods: kyverno.io/docs/installation/methods
• Kyverno CLI: kyverno.io/docs/kyverno-cli
• Kyverno policy library: kyverno.io/policies
• Kyverno version referenced: v1.17.0, released February 2026