Challenges
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Michal_Gebacki
Community Team
Community Team
Level: Beginner

This Challenge Level is best suited for:

 
Platform engineers, SREs, and developers curious about Kubernetes security — no prior Kyverno experience needed, but familiarity with basic kubectl and YAML will help.

Mission objective

 
All workloads missing the republic.rome/gens label are blocked at admission with a clear policy violation message
 
All workloads running as privileged containers are blocked at admission with a clear policy violation message
 
All pods declaring republic.rome/traveler: peregrinus automatically receive the republic.rome/travel-permit: granted label
 
All other workloads deploy and run successfully in the cluster
 

Key Learnings

 
How Kyverno ValidatingPolicy resources and CEL validation expressions work
 
The difference between Audit, Deny, and Warn validation actions
 
How to use custom label keys to enforce workload identity standards
 
How Kyverno MutatingPolicy resources automatically patch incoming workloads at admission

This Challenge’s Level story:

The Republic’s legal scholars have been busy — perhaps too busy. In their haste to codify the Twelve Tables, the foundation of the Republic’s legal system, they introduced errors that now threaten the city’s order. Workloads that should be blocked are running freely, and workloads that should be allowed are being turned away at the gates.

Another scholar left a note: “I tried to set up policies for privileged containers and required labels, but something’s off — I can’t figure out why the wrong things are getting through. There was also supposed to be a system for automatically issuing travel permits to foreign visitors, but that one is broken too.”

Your mission: investigate the Kyverno policies and restore proper admission control before chaos reaches the city.

This Challenge Level’s architecture:

 
The Twelve Tables enforced Roman law at the gates — before a citizen could act, not after the damage was done. Kyverno works the same way: it intercepts every workload request before it reaches the cluster. A misconfigured policy doesn’t just fail to enforce — it fails silently, letting non-compliant workloads slip through while you assume everything is fine.
 
Your Codespace comes with a Kubernetes cluster and Kyverno pre-installed. Three broken policies are already deployed in manifests/policies/ — two ValidatingPolicy resources and one MutatingPolicy. Edit them directly and re-apply with kubectl. The pods in manifests/pods/ are for reference only — no GitOps, no dashboards.

Walkthrough

1. Get started

Open in GitHub Codespaces. The devcontainer is pre-configured and starts automatically. When you push from Codespaces, GitHub forks the repository to your account automatically.

Prefer working locally? Clone the repo and open it in any editor that supports the Dev Containers specification (VS Code, JetBrains IDEs, and others). The devcontainer config will be detected automatically.

2. Explore the Cluster

When your Codespace is ready, four pods are already running — or trying to. Open a terminal and check what’s going on:

kubectl get pods

Inspect why a pod was blocked or admitted:

kubectl describe pod <pod-name>

List and inspect the policies:

kubectl get validatingpolicies
kubectl get validatingpolicy require-labels -o yaml
kubectl get validatingpolicy no-privileged-containers -o yaml

kubectl get mutatingpolicies
kubectl get mutatingpolicy stamp-travel-permit -o yaml

You can also launch k9s for a terminal UI view of all cluster resources:

k9s

Navigate to ValidatingPolicy resources with :validatingpolicies and MutatingPolicy resources with :mutatingpolicies to inspect all three policies.

3. Fix the policies

Review the objectives of this mission that are visible in the top of this page and investigate what’s wrong in manifests/policies/.

All three broken policies are in manifests/policies/. Read them carefully — each has a different kind of misconfiguration.

Test Locally with the Kyverno CLI

Before applying to the cluster, you can use the kyverno CLI to test your policy changes locally against the workload manifests:

kyverno apply manifests/policies/require-labels.yaml --resource manifests/pods/
kyverno apply manifests/policies/no-privileged-containers.yaml --resource manifests/pods/
kyverno apply manifests/policies/stamp-travel-permit.yaml --resource manifests/pods/

This gives you fast feedback without touching the cluster.

Apply to the Cluster

Once you’re happy with your changes, re-apply everything:

make apply

This re-applies the policies and re-deploys all workloads so you immediately see the effect of your changes.

How to complete your challenge?

 
When you push from Codespaces, GitHub forks the repository to your account automatically. If you are working locally, fork the repository on GitHub before pushing.
 

Verify your solution:

./verify.sh
 
If it passes, it generates a Certificate of Completion you can paste into the discussion.
 
Share your solutions in this thread in answer below and mention your achievement on your LinkedIn account!

Toolbox

kubectl - Apply and inspect cluster resources

kyverno CLI - Test and lint policies locally before applying

k9s - Explore cluster resources in a terminal UI

 

Helpful documentation

Kyverno ValidatingPolicy

Kyverno MutatingPolicy

CEL Validation Expressions

Kyverno Playground

Are you ready? Take the challenge’s mission!

Open in Codespaces

 
Free GitHub account required.
 
Launch in a preconfigured devcontainer.
 

Don’t forget about benefits!

 
For completing at least one level you get a unique badge!
 
For completing all of the three levels you get even more badges!
 
Deadline: 12 August 2026 at 23:59 CET

Other levels of this challenge

🔒 Available 22 July 2026 Governing the provinces
🔒 Available 29 July 2026 Quis Custodiet
1 Comment