Kyverno — Kubernetes Policy Engine
The policy engine that keeps policy inside Kubernetes itself. Learn the CEL-based policy types, the four controllers and how they split the work, writing and enforcing validations, image signature verification, the Kyverno CLI, and policy reports and exceptions — remembered with spaced repetition.
- flashcards
- 95
- flashcards
- per day
- ~10 min
- per day
- level
- Intermediate
- level
- modules
- 6
- modules
What is Kyverno?
Kyverno is a CNCF policy engine for Kubernetes that runs as an admission controller: the API server calls it while a request is in flight, and its answer decides whether the resource is admitted, rewritten, or rejected. Its defining choice is that policies are ordinary Kubernetes resources, so they are written, reviewed and shipped with the same tools as everything else in the cluster.
A Kyverno policy can do four different jobs. It can validate a resource and block it, mutate one in flight or after the fact, generate or clone downstream resources when a trigger appears, and verify container image signatures and attestations before a workload is allowed to run. Alongside admission it also scans resources that are already stored, recording what it finds in policy reports rather than breaking running workloads.
The part worth knowing before you start is that the policy model changed. The current types — ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy and ImageValidatingPolicy — live in the policies.kyverno.io group and express their logic in CEL, the same language Kubernetes uses for its own admission policies. The older ClusterPolicy is deprecated and slated for removal, so this track teaches the current API and flags the migration where it matters. If you are sitting the exam, the KCA guide walks the blueprint by weight; if you are still choosing an engine, see Kyverno vs OPA and Gatekeeper.
6 modules, seed to bloom
Each module is a set of flashcards — 95 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Fundamentals
What Kyverno is, its policy types and how it evaluates resources
16 cardsInstallation & Configuration
Controllers, Helm installation, high availability and webhook configuration
16 cardsWriting Policies
ValidatingPolicy structure, CEL expressions, matching and enforcement actions
16 cardsMutation, Generation & Images
MutatingPolicy patches, GeneratingPolicy sources and image signature verification
15 cardsKyverno CLI
Applying and testing policies outside the cluster, and the test manifest format
15 cardsApplying & Managing Policies
Admission and background evaluation, policy reports and exceptions
17 cardsSample questions
A taste of the real flashcards. Pick an answer, then reveal the explanation.
What most clearly distinguishes Kyverno's policy model from OPA Gatekeeper's?
- AKyverno expresses policy in CEL inside its own CRDs rather than in Rego modules
- BKyverno evaluates policy inside the API server rather than in an external webhook
- CKyverno enforces policy at the container runtime rather than at admission time
- DKyverno stores policy in an external database rather than as cluster resources
Which field decides what happens when a ValidatingPolicy's expression fails?
- Aspec.validationActions, a list of the enforcement actions the engine should take
- Bspec.failurePolicy, a setting for how the API server treats an unreachable webhook
- Cspec.evaluation.mode, a setting that selects Kubernetes or JSON payload evaluation
- Dspec.validations.severity, a label that grades how serious the violation is
Which setting makes a MutatingPolicy apply to resources that are already in the cluster?
- Aspec.evaluation.mutateExisting.enabled, which hands the work to the background controller
- Bspec.evaluation.admission.enabled, which applies the policy to CREATE and UPDATE requests
- Cspec.reinvocationPolicy, which asks the engine to run the mutation more than once
- Dspec.mutations.patchType, which selects how the change to the resource is expressed
Which resource holds Kyverno's results for resources inside a single namespace?
- APolicyReport, created in the same namespace as the resources it describes
- BClusterPolicyReport, created once per cluster and filtered by namespace label
- CAdmissionReport, created per request and retained as the namespace's record
- DPolicyException, created per namespace to record which rules were waived there
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why Kyverno is worth your time
Policy without a second language
Rules are Kubernetes resources with CEL expressions, so there is no Rego module and no separate toolchain to learn before you can write your first guardrail.
Guardrails that scale past code review
Required labels, resource limits, blocked privilege escalation — enforced by the cluster rather than by someone remembering to check a pull request.
Supply-chain checks at admission
Verify Cosign signatures and attestations before a workload starts, and pin the tag to the digest that was actually verified.
Straight prep for the KCA exam
The modules mirror the Kyverno Certified Associate blueprint, so the heaviest domains get the most practice.
Common questions
Do I need to know Kubernetes first? +
A working grasp of pods, deployments and namespaces helps, because Kyverno policies act on those resources. The track explains Kyverno itself from the ground up, starting with what the engine is and how admission control works.
Does this cover ClusterPolicy or the newer CEL policy types? +
The CEL types — ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy and ImageValidatingPolicy. ClusterPolicy is deprecated and due for removal, so it appears only where the deck teaches how a legacy field maps to its replacement.
Is this enough to pass the Kyverno Certified Associate exam? +
It covers the blueprint domains and weights them the way the exam does, which is the recall half of the work. Pair it with hands-on practice against a real cluster and with the official exam guide — Gnoseed is a free study companion, not a course or an exam dump.
How does Kyverno compare with OPA and Gatekeeper? +
Both gate admission; the difference is how a rule is written. Kyverno uses CEL inside its own custom resources, while Gatekeeper compiles Rego supplied through ConstraintTemplates. Kyverno is Kubernetes-only, whereas OPA also runs outside the cluster.
Is it free? +
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
Ready to make your clusters enforce their own rules?
Plant your first seed today. Ten minutes a day is all it takes to turn the policy model into recall you can rely on.