Kubernetes will happily run almost anything you give it, and that freedom is exactly the problem.

Kubernetes is a system that runs containers for you. You describe what you want in a text file, send it to the cluster, and Kubernetes makes it real. That description is called a manifest. Out of the box, Kubernetes checks that a manifest is shaped correctly. It does not check whether the manifest follows your company’s rules. If a developer asks for a container that runs with full administrator power on the machine, Kubernetes will say yes, because the request is valid, even though it is risky.

In a small team, people can review each other’s work and catch mistakes by eye. In a large company with dozens of teams and thousands of deployments each week, human review does not scale. People forget, people are in a hurry, and new joiners do not know every rule. You need something that enforces the rules automatically, at the exact moment a request arrives, before the risky thing is created. That something is a policy engine.

What kinds of rules do teams usually want?

Most organizations end up with a similar list. They want every workload to carry labels so cost and ownership can be tracked. They want containers to avoid running as the all-powerful root user. They want images to come only from trusted registries. They want resource limits so one greedy application cannot starve its neighbors. They want certain security settings switched on by default. And they want these rules to be written down in a form that can be reviewed, versioned and tested like any other code.

Kyverno is a policy engine built for Kubernetes, using Kubernetes’ own style of resources to describe rules.

The name Kyverno comes from a Greek word meaning “to govern”. It started in 2019, created by a company called Nirmata, and was given to the Cloud Native Computing Foundation, usually shortened to CNCF, in 2020. The CNCF is the neutral home for many famous cloud tools. Kyverno entered as a sandbox project, moved up to incubating in 2022, and reached the top maturity level, called graduated, in March 2026. Graduation means the project passed security reviews, has a healthy and diverse set of contributors, and is trusted in real production systems around the world.

What makes Kyverno different is how you write rules. In many older policy tools, you must learn a separate programming language just to describe a rule. Kyverno took a different path: policies are Kubernetes resources. They are stored in the cluster, listed with the same tools you already use, protected by the same access controls, and managed through the same pipelines as your other resources. If you already understand how Kubernetes describes a Deployment or a Service, the shape of a Kyverno policy will feel familiar.

The four jobs Kyverno does

Kyverno does much more than say “no”. Over the years its abilities grew into a family of jobs, and each job has its own purpose.

There are also supporting jobs: cleaning up old resources on a schedule, reporting the results of every check, and letting you grant carefully controlled exceptions. You will meet all of them in this guide.

To understand Kyverno, you first need to understand the path every request takes through the Kubernetes API server.

Everything in Kubernetes goes through one front door called the API server. When you create a pod, update a deployment or delete a secret, you are sending a request to the API server. Before that request is saved into the cluster’s database, it passes through several stages. First comes authentication, which asks who you are. Then authorization, which asks whether you are allowed to do this. Then comes the stage Kyverno cares about: admission control.

Admission control is a set of checkpoints that look at the content of the request itself. There are two kinds. Mutating admission can change the request. Validating admission can only accept or reject it. Kubernetes runs all the mutating checkpoints first, then checks the shape of the final object, and then runs all the validating checkpoints. Only if everything agrees does the object get saved.

flowchart LR
  A["Client sends request"] --> B["Authentication: who are you?"]
  B --> C["Authorization: are you allowed?"]
  C --> D["Mutating admission"]
  D --> E["Schema validation"]
  E --> F["Validating admission"]
  F --> G["Saved in etcd"]
        

Webhooks: how outside programs join the checkpoint

Kubernetes lets outside programs join the admission stage using something called a webhook. A webhook is simply a web address that Kubernetes calls with the request details, asking “what do you think?”. The outside program answers yes or no, and for mutating checkpoints it can also say “yes, but change these things first”. Kyverno registers itself as both a mutating and a validating webhook. That is how it gets a chance to look at every request that matches its policies.

Why the failure behavior matters

Because the API server waits for the webhook’s answer, the webhook becomes part of the critical path. If the webhook is slow, requests become slow. If the webhook is unreachable, Kubernetes must decide what to do. Each webhook has a failure setting: fail closed means requests are rejected when the webhook cannot answer, and fail open means requests are allowed through. This single setting is one of the most important design decisions in a policy deployment, and we will return to it when we talk about high availability.

Kyverno is not one big program. It is a small team of specialized controllers, each doing one kind of work.

When you install Kyverno, you get several deployments running in the cluster, usually in their own namespace. Splitting the work this way is a deliberate design choice. It lets each part scale on its own, fail on its own, and be given only the permissions it truly needs. A controller, in Kubernetes language, is a program that watches the cluster and keeps working until reality matches what is wanted.

flowchart TD
  API["Kubernetes API Server"]
  ADM["Admission Controller"]
  BG["Background Controller"]
  REP["Reports Controller"]
  CLN["Cleanup Controller"]
  POL["Policy resources"]
  RES["PolicyReport resources"]
  API -- "webhook calls" --> ADM
  POL --> ADM
  POL --> BG
  BG -- "generate and mutate existing" --> API
  ADM -- "ephemeral results" --> REP
  BG -- "scan results" --> REP
  REP --> RES
  CLN -- "delete on schedule" --> API
        

Why separate permissions are a feature

Each controller runs with its own service account and its own set of permissions. The admission controller must be able to read many kinds of resources to evaluate rules. The cleanup controller needs permission to delete only what your cleanup rules target. If one component were compromised, the damage would be limited to what that component was allowed to do. This is the principle of least privilege applied to the policy engine itself.

Kyverno has recently gone through its biggest change: a new family of policy types built on the Common Expression Language.

For years, Kyverno’s rules lived in two resource types: ClusterPolicy, which applies cluster-wide, and Policy, which applies inside a single namespace. Both used Kyverno’s own rule engine, with its own pattern-matching syntax and its own way of querying data. It worked well and many organizations built large policy libraries on it.

Meanwhile, Kubernetes itself introduced a built-in way to write validation rules using the Common Expression Language, shortened to CEL. CEL is a small, fast language for writing safe expressions such as “this value must be less than that value”. Kubernetes chose CEL for its native admission policies because it is quick to evaluate and cannot run wild loops or reach outside the sandbox. Kyverno decided to align with this direction rather than compete with it.

According to the project’s own release announcements, version 1.17, released in February 2026, promoted the CEL-based policy types to stable status, called v1 or generally available. At the same time, the older ClusterPolicy approach was marked deprecated, with removal planned for a later release in the second half of 2026. The CEL-based family includes policy types dedicated to each job.

Why the change helps you

The CEL-based types give you a more focused structure. Instead of one giant policy shape that can do everything, each type has fields that suit its job. They also benefit from CEL’s speed and from the fact that Kubernetes’ own native policies use the same language, so skills transfer between the two worlds. Kyverno adds extra function libraries on top of standard CEL so that it can still do things the native engine cannot, such as looking at other resources in the cluster or checking image signatures.

Validation is the most common use of Kyverno: read the resource, test a condition, and decide what happens next.

A validation policy has three ingredients. The first is a match: which kinds of resources and which operations should this policy look at? The second is the condition, written as one or more expressions that must be true for the resource to be acceptable. The third is the action: what should happen when the condition is false? Kubernetes-style validation actions give you three choices, and picking among them is where much of the real-world skill lies.

Writing good messages

The message attached to a rule is shown to the person whose request was rejected. A poor message such as “validation failed” makes people angry and sends them to your support channel. A good message says what rule was broken, why the rule exists, and what to change. Treat policy messages as part of your product. The people reading them are your customers.

Variables and reuse

Real rules often need the same piece of data several times, such as the list of containers in a pod, including the init containers and the temporary ones. CEL-based policies let you define named variables once and reuse them in several expressions. This keeps rules short, readable and easier to test. It also means a mistake in how you collect the container list is fixed in one place.

Matching the right requests

Policies can match by resource kind, by operation such as create or update, by namespace, by labels, and by who is making the request. Narrow matching is a performance feature as well as a correctness feature. A policy that matches only pods costs nothing for a request about a config map. A policy that matches everything makes the engine work on every single request.

Mutation lets Kyverno fix things for people instead of just telling them off.

Rejecting a request is sometimes the wrong tool. Imagine a hundred teams, and a new company rule says every container must drop a dangerous capability by default. If you only validate, every team gets an error and must edit its manifests. If you mutate, Kyverno adds the safe setting automatically and nobody is interrupted. Mutation is how platform teams provide safe defaults without creating friction.

Mutation happens during the mutating stage of admission, before the object is stored. Kyverno receives the request, applies the changes, and sends back a description of the changes. The API server applies them and then moves on to the validation stage. This ordering is important: because validation runs after mutation, your validation rules see the final, mutated object.

Mutating existing resources

Normal mutation only affects resources entering the cluster. Kyverno can also change resources that already exist, using the background controller. For instance, when a particular config map changes, you can update all the deployments that depend on it. This is a powerful pattern and also a dangerous one, because it changes live objects without a human in the loop. Use it with narrow matching and careful testing.

Common mutation use cases

Generation makes Kyverno a builder: when one thing appears, it creates the supporting things automatically.

Every time a team asks for a new namespace, a platform engineer used to do the same chores by hand. Add a default network rule. Add a quota so the team cannot use unlimited resources. Add a role binding so the team can work in its space. Add a standard config map. These are repetitive, easy to forget, and easy to get slightly wrong. A generation policy watches for a trigger, such as a new namespace, and creates all the companion resources at once.

sequenceDiagram
  participant Dev as Developer
  participant API as API Server
  participant BG as Background Controller
  Dev->>API: Create namespace
  API-->>Dev: Namespace saved
  BG->>API: Watches for new namespaces
  BG->>API: Create default network rule
  BG->>API: Create resource quota
  BG->>API: Create role binding
        

Keeping generated resources in sync

Generation has a clever extra feature: synchronization. When synchronization is on, Kyverno treats the policy as the source of truth. If someone edits or deletes a generated resource by hand, Kyverno puts it back the way the policy describes. If you change the policy, the generated resources follow. When the trigger resource is deleted, the generated ones can be cleaned up with it. This gives you a lifecycle that matches the trigger, rather than a pile of orphaned objects.

Cloning versus creating from scratch

A generation policy can build a resource from a description inside the policy, or it can clone an existing resource from another namespace. Cloning is useful when the source of truth is a carefully maintained object, such as a shared registry credential that every namespace needs. You update the original once, and every clone follows.

A container image is a program someone else built. Kyverno helps you confirm who built it and that nobody tampered with it.

Every pod runs an image pulled from a registry. If an attacker slips a malicious image into the registry, or tricks a developer into using a lookalike name, your cluster will happily run it. The set of steps that take code from a developer’s laptop to a running container is called the software supply chain, and attacking it has become a favorite technique of serious adversaries. Verifying images at admission time closes one of the most important doors.

Signatures and attestations

A signature is a cryptographic proof, attached to an image, that a particular trusted identity approved it. Tools in the Sigstore ecosystem, with Cosign being the best known, make signing practical. An attestation goes one step further. It is a signed statement about the image, such as “this image was built by our pipeline”, “this image passed vulnerability scanning on this date”, or “here is the list of ingredients inside it”, which is called a software bill of materials. Kyverno can check both.

Kyverno’s image verification policy type reaches out to the registry, fetches the signature and attestations, checks them against the keys or identities you trust, and decides whether to allow the pod. It can also rewrite the image reference from a movable tag to an exact fixed digest, so that what was verified is exactly what runs. This closes a subtle gap: a tag like “latest” can be moved to a different image after you checked it, but a digest cannot.

Clusters collect clutter. Kyverno can sweep it away on a schedule, following rules you wrote down.

Anyone who has run a shared cluster knows the mess that builds up. Test pods that nobody deleted. Completed jobs that stay for months. Temporary namespaces created for a demo and forgotten. Each leftover costs money and adds noise. Kyverno’s cleanup features let you describe which resources are eligible for deletion and when to look for them. The cleanup controller then wakes up on schedule, finds matching resources, and deletes them.

Two ways to clean up

The first way is a scheduled rule: on a repeating timetable, find every resource that matches certain conditions and delete it. The second way is a time-to-live label. A resource is stamped with a label saying how long it may live, and Kyverno removes it when that time is up. This is wonderful for short-lived environments, because the person creating something can decide its lifetime right at creation, and forgetting to clean up no longer costs money.

Some rules cannot be decided by looking at the incoming object alone. They need extra facts from the cluster or from the outside world.

Imagine a rule that says “a service may only use a hostname that no other service already uses”. The incoming object cannot answer that. Kyverno must also look at other services in the cluster. Or imagine a rule that depends on a list of approved registries kept in a config map that the security team updates. Kyverno needs to read that config map at evaluation time. Collecting these outside facts is called bringing in context.

Sources of context

A policy is only as good as its aim. Matching decides what it sees, and exclusions decide what it must leave alone.

Every Kyverno policy begins with a statement of what it applies to. You can match by kind, such as pods or deployments. You can match by operation: create, update, delete or connect. You can match by namespace, by namespace labels, by object labels, and by details of the user making the request. Matching well matters for two reasons. It keeps the rule from hitting things it was never meant for, and it keeps the engine fast, because irrelevant requests are skipped quickly.

Why some namespaces are special

Every cluster has system namespaces holding the parts that make Kubernetes work. If a policy blocks something those components need, the cluster can stop healing itself. Kyverno ships with resource filters and sensible defaults that skip some system areas, and good policy authors also exclude system namespaces explicitly. Kyverno’s own namespace deserves special care: if a rule prevents Kyverno’s own pods from starting, you may lock yourself out of fixing the problem.

Scope by tier

Many organizations use layers of scope. Cluster-wide policies, owned by the platform and security teams, cover rules that never change, such as banning privileged containers. Namespaced policies, owned by each application team, cover local rules, such as naming conventions for that team’s own resources. This split lets teams govern themselves without being able to weaken the global rules.

Blocking new problems is half the story. You also need to see the old problems that were already there.

Admission control only sees requests as they happen. A deployment created last year, before a rule existed, never faced that rule. Kyverno therefore runs background scans, which periodically re-check existing resources against your policies. The results, together with the results from live admission checks in audit mode, are written into report resources that you can read like any other Kubernetes object.

The reports follow a common format shared across the Kubernetes policy ecosystem. Each report lists resources and, for each one, whether it passed, failed, produced a warning, was skipped, or caused an error. Namespaced resources go into namespaced reports. Cluster-level resources go into cluster reports. Because reports are normal resources, you can query them with standard tools, display them in dashboards, or feed them to alerting systems.

flowchart LR
  A["Live admission check"] --> R["Reports Controller"]
  B["Background scan"] --> R
  R --> N["Namespaced PolicyReport"]
  R --> C["ClusterPolicyReport"]
  N --> D["Dashboards and alerts"]
  C --> D
        

Seeing reports in a friendlier way

Raw report resources are accurate but not pretty. The Kyverno ecosystem includes a companion project that turns reports into dashboards, sends alerts to chat tools and ticket systems, and exposes metrics for monitoring. Many teams treat it as the human face of their policy program.

Rules without any way to bend them will eventually be worked around. Exceptions let you bend them safely.

No rule fits every situation. A legacy monitoring agent may truly need host access. A migration tool may need to run as the root user for a week. If your only options are “follow the rule” or “delete the rule”, people will pressure you to delete it, and then nobody is protected. Kyverno offers a dedicated exception resource that says, in writing, that a specific workload is excused from a specific rule.

What a good exception process looks like

A policy is code, and code that can reject every deployment in your company deserves serious testing.

Policies are powerful because they affect everything. That also makes mistakes costly. A policy with a typo in its condition might reject every pod, including the ones needed to repair the problem. Mature teams therefore test policies the same way they test software, in layers, and well before production.

What to test

Good test suites include both good and bad examples. A pass case proves a correct resource is allowed. A fail case proves a bad resource is blocked. Edge cases matter most: containers with unusual names, init containers, resources missing optional fields, and updates as well as creates. Teams that skip edge cases often find them in production, at the worst time.

The technical part of Kyverno is easy to install. The human part, getting teams to accept it, is where projects succeed or fail.

The most common failure story goes like this. A security team installs Kyverno, switches on a pile of deny rules on a Friday, and by Monday dozens of teams cannot deploy. Trust collapses, rules are removed, and the project is called a failure. A careful rollout avoids this by moving through clear stages and communicating at each step.

flowchart LR
  A["Write policy in Git"] --> B["Test with CLI and Chainsaw"]
  B --> C["Audit in staging"]
  C --> D["Audit in production"]
  D --> E["Warn developers"]
  E --> F["Enforce with deny"]
  F --> G["Review and improve"]
  G --> A
        

Policies as code in Git

Store every policy in version control, review changes through pull requests, and let a GitOps tool apply them to clusters. This gives you a history of who changed which rule and why, an easy way to roll back, and the same review culture you already use for application code. It also prevents the dangerous habit of editing policies directly in a live cluster.

Because Kyverno sits on the request path, its reliability becomes the cluster’s reliability.

If the admission controller goes down while the webhook is set to fail closed, nobody can create or update the resources covered by the webhook. If it is set to fail open, policies silently stop protecting you during the outage. Neither outcome is comfortable, so production setups invest in keeping the admission controller healthy.

Run more than one copy

The standard advice is to run several replicas of the admission controller, spread across different machines and failure zones, with disruption budgets so that routine maintenance never takes all of them down at once. Kyverno’s documentation recommends multiple replicas for production, commonly three. Controllers that do background work use leader election, which means only one copy is the active worker at a time while the others wait to take over.

Fail closed or fail open?

Keeping it fast

The guard at the door must also be guarded. Kyverno has wide read access and can change resources, so it is a valuable target.

To do its job, Kyverno needs permissions across many parts of the cluster. That makes it attractive to an attacker. If someone could change your policies, they could switch off protections or even use mutation and generation to plant dangerous resources. Securing Kyverno means securing who can touch policies, who can touch Kyverno’s own deployments, and what each controller is allowed to do.

Release support and upgrades

The project has announced a support model where the current release and the one before it receive patches. In practical terms, that means you should not fall many versions behind. Plan regular upgrades, read the upgrade notes for removed or deprecated features, and test the upgrade in a non-production cluster first.

You cannot manage what you cannot see. Good observability tells you whether policies are healthy, fast and effective.

Observability means being able to ask questions about a running system and get answers. For Kyverno, the questions fall into three groups: Is it healthy and fast? Are policies doing what we expect? And when a request is rejected, why exactly? Three kinds of signals help: metrics, logs and traces.

What to watch

Kyverno is not the only way to enforce rules. Knowing the neighbors helps you choose the right tool for each job.

Kubernetes now includes its own built-in validation feature, called ValidatingAdmissionPolicy, which uses CEL and runs inside the API server with no webhook at all. It is fast and has no extra component to maintain. It is also intentionally focused: it checks the incoming object and allows or rejects it. Another popular tool is OPA Gatekeeper, a policy engine built on the Open Policy Agent project, where rules are written in a separate language called Rego. Both Kyverno and Gatekeeper are CNCF graduated projects.

How to choose

If you already run Kyverno, the most important project on your list for the coming months is likely this migration.

The legacy ClusterPolicy and Policy resources have been marked deprecated, and the project has published a migration guide that maps old fields to their new equivalents. Removal is planned for a release later in 2026. Because dates can move, check the official announcements, but treat the direction as settled: the CEL-based types are the future, and new work should start there.

When many teams share one cluster, Kyverno becomes the tool that gives each team freedom inside safe walls.

Multi-tenancy means several independent groups, called tenants, share the same infrastructure. Each tenant wants to move fast. The platform team wants everyone to stay safe and fair. Kyverno helps by creating the walls automatically when a tenant is onboarded and by enforcing the rules that keep tenants from harming each other.

flowchart TD
  T["New team onboarded"] --> N["Namespace created"]
  N --> G["Generation policy adds quota, network rules and access"]
  G --> M["Mutation policy adds labels and safe defaults"]
  M --> V["Validation policies check every deployment"]
  V --> I["Image policy verifies signatures"]
  I --> R["Reports show compliance to the platform team"]
        

The paved road idea

Platform teams often talk about a paved road: the easy, well-lit path that most teams should follow. Kyverno supports this by making the safe way the default way. Mutation fills in sensible settings so teams do not have to know every detail. Validation catches the rare case that falls off the road. Generation builds the road for every new neighborhood. Teams that stay on the road have almost no friction, while teams that need something different can request an exception.

Experienced teams keep running into the same shapes of good and bad design. Learn them early.

Patterns that work

Patterns that hurt

A short checklist of habits that separate calm policy programs from stressful ones.

Three questions before adding any rule

Different industries use the same tool for different worries. Here is how the ideas look in practice.

Let us follow one single pod creation from the developer’s keyboard all the way to a stored object, noticing every moment Kyverno gets involved.

Understanding the exact sequence of events removes most of the mystery from Kyverno. When something surprising happens, you can ask yourself at which step it happened. The journey has more steps than most people expect, and each one has a different owner and a different failure mode.

sequenceDiagram
  participant Dev as Developer
  participant API as API Server
  participant KY as Kyverno Admission
  participant ET as etcd Store
  participant RP as Reports Controller
  Dev->>API: Create pod request
  API->>API: Authenticate and authorize
  API->>KY: Mutating webhook call
  KY-->>API: Changes to apply
  API->>API: Check object shape
  API->>KY: Validating webhook call
  KY-->>API: Allow or deny with message
  API->>ET: Save object if allowed
  KY->>RP: Send result for reporting
  API-->>Dev: Success or error message
        

Why this order has consequences

Because mutation comes before validation, validation rules always see the finished object. This means you can rely on a mutation policy to add a label and then write a validation policy that requires the label, and the two will agree. It also means that when you test a validation policy using a raw manifest, you may get a different result from the live cluster, because the live cluster applied changes first. Good test suites account for this by testing the mutated form as well.

Behind each allow or deny is a small pipeline of matching, preparing data, running expressions and building an answer.

When the admission controller receives a call, it does not read policies fresh from the cluster each time. That would be far too slow. Instead, it keeps a cache of policies that it updates as policies change. Policy resources are watched, and when one is created, edited or removed, the cache updates within moments. The expressions inside CEL-based policies are compiled ahead of time into an efficient form, so that at request time the engine only needs to run them against the incoming data.

The evaluation pipeline

flowchart LR
  A["Incoming request"] --> B["Find matching policies from cache"]
  B --> C["Apply exclusions and exceptions"]
  C --> D["Load context and variables"]
  D --> E["Run compiled expressions"]
  E --> F["Combine results"]
  F --> G["Build response and report entry"]
        

Pod controllers and automatic rule extension

People rarely create bare pods. They create deployments, stateful sets, daemon sets and jobs, which then create pods. If a policy about pods only matched pods, it would catch a bad deployment late, when the deployment’s controller tries to create the pods and fails, leaving the developer with a confusing situation where the deployment exists but no pods appear. Kyverno’s legacy engine had an automatic feature that extended pod rules to the controllers that make pods. The newer policy types handle this through their own matching options and the way policies are written, so check the current documentation for how your chosen policy type treats pod-creating resources. The goal is always the same: tell the developer about the problem at the earliest, most visible moment.

Idempotence: running twice must equal running once

A well-behaved mutation policy gives the same final object whether it runs once or several times. If each run added another copy of the same item, repeated runs would pile up duplicates. Writing policies that check the current state before changing it, and that describe the desired end state, avoids this trap.

Policies are living things. They are proposed, tested, enforced, tuned and eventually retired, and each stage needs an owner.

Many organizations treat policies as a one-time installation. Over the years, the rule list grows and nobody remembers why half of them exist. Some rules block harmless work, some duplicate each other, and some protect against problems that were fixed long ago. A healthy program manages the whole lifetime of every rule with the same discipline used for software products.

Ownership and metadata

Every policy should name an owner, a reason, a severity and a link to its proposal. Kyverno policies can carry annotations and labels for this purpose, and the public policy library uses annotations to describe each rule’s title, category and purpose. Adopting a consistent set of annotations makes it easy to build a catalog that anyone can search. A question like “which policies protect payment workloads, and who owns them?” should have a one-minute answer.

Versioning and communication

Treat changes to policies like changes to a public interface. Small fixes can flow quickly. Changes that make a rule stricter should be announced in advance with a date. A short, regular newsletter or channel post listing upcoming policy changes does more for trust than any technical feature.

For many companies, the main reason to adopt policy-as-code is to answer auditors quickly and honestly.

Industry standards and regulations ask for controls such as least privilege, separation of tenants, approved software only, encryption in transit and logging. Auditors do not simply accept “we have a rule”. They ask for proof that the rule applies everywhere and that exceptions are controlled. Doing this by hand with spreadsheets and screenshots is slow and easily becomes out of date. With Kyverno, the policy is the written rule, the admission result is the enforcement, and the policy report is the evidence.

Mapping policies to controls

A practical approach is to build a simple mapping table. Each row names a control from the standard you follow, the Kyverno policy that supports it, the mode it runs in, and where the evidence can be found. This table becomes the first thing you hand to an auditor, and it shows you gaps, which are controls that no policy supports yet.

When something goes wrong, a calm, ordered investigation beats guesswork every time.

Almost every Kyverno problem falls into one of a few families: a request was denied and the developer does not understand why, a policy seems to be ignored, a generated resource did not appear, or the cluster has become slow. For each family there is a short list of checks, and following the list in order finds the cause quickly.

Family 1: “Why was my request denied?”

Family 2: “My policy is being ignored”

Family 3: “My generated resource never appeared”

First confirm that the background controller is running and healthy. Then check its permissions, because it can only create what its service account allows. Next confirm the trigger really matches, and read the controller’s logs for errors about the target resource. Finally look at whether the policy’s synchronization and update settings are what you expect.

Family 4: “Everything feels slow”

Look at admission latency metrics and find out whether the slowness began after a particular policy change. Inspect policies that make external calls or load large amounts of context. Check whether the admission controller pods are short of memory or processing power, or whether requests are queuing. Narrowing policy matching often gives the biggest improvement.

Kyverno began as a Kubernetes admission tool, but the same policy idea can guard many other doorways.

The most visible place for Kyverno is the Kubernetes admission path, but the ideas apply anywhere data needs to be checked against rules. Over time, the project has grown tools that work before and beyond admission. Public CNCF material about the graduation also states that upcoming releases aim to extend policy enforcement to additional control points across the cloud native stack, including gateways for artificial intelligence and Model Context Protocol traffic. Because plans can change, treat this as a direction rather than a promise, and check the roadmap when you plan.

Shift left: catch problems sooner

The phrase shift left means moving checks earlier in the journey, toward the developer. A rule violation found on a laptop costs a few seconds to fix. The same violation found in production costs a deployment failure, a message to the platform team and a lost afternoon. Running the same policies in pipelines and again at admission gives two chances to catch an issue, and the developer usually meets it at the cheapest moment.

Installing Kyverno is day one. Keeping it healthy for years is day two, and it deserves the same planning.

A policy engine on the critical path of every deployment is a piece of platform infrastructure, so it needs regular care. The tasks are not exciting, but skipping them is how teams end up with a surprise outage or a security gap.

Upgrades

Kyverno releases frequently, and the project supports the current release and the one before it for patches. Falling several releases behind removes you from that safety net. A reliable routine looks like this: read the release notes and upgrade guide, note any removed or changed features, upgrade a test cluster first, run your policy tests and watch reports and metrics, and only then upgrade production, one cluster at a time. Because the project is in the middle of retiring its legacy policy types, upgrade notes deserve extra attention in the coming releases.

Backup and disaster recovery

If policies live in Git and are applied by an automated pipeline, rebuilding a lost cluster is mostly a matter of reinstalling Kyverno and letting the pipeline apply the policies again. That is a strong reason to keep Git as the source of truth. Also keep the installation settings, such as replica counts and webhook behavior, in version control. Remember that reports are generated data and can be rebuilt by background scans, although historical report data lives only in whatever monitoring system you exported it to.

Capacity planning

Start with the recommended replica counts from the documentation, then adjust based on measured latency and memory use. Watch trends rather than single numbers: a slow, steady growth in memory or latency is an early warning that you will soon need more capacity or fewer, better-targeted policies. Load test in a staging cluster by creating many resources quickly, so you learn the limits before production does.

Short, direct answers to the questions people ask most often when they start working with Kyverno.

No. Access control decides who is allowed to perform an action. Kyverno decides whether the content of the request is acceptable. The two work together, and neither replaces the other.

Policies are Kubernetes resources, so the surrounding structure is familiar. The newer policy types use CEL for their conditions, which is a small expression language that is much simpler than a general programming language and is shared with Kubernetes’ own native policies.

Existing resources are not blocked or deleted by a validation policy. The background scan checks them and records the results in reports, so you can see what would fail. Mutation and generation of existing resources are separate, deliberate features.

It adds a small amount of time to matching requests, because the API server waits for its answer. Narrow matching, enough replicas, cached lookups and avoiding slow external calls keep that cost low.

It depends on the webhook failure setting. Fail closed rejects covered requests while Kyverno is unavailable. Fail open lets them through unprotected. Running multiple replicas and monitoring health greatly reduces the chance of either situation.

Start with audit so you can see the impact, add warnings to educate people, and move to enforcement when the rule is understood and teams are ready. Critical safety rules usually end up enforced.

Yes. Namespaced policy types let teams manage rules inside their own namespaces, while cluster-wide rules stay under platform and security control.

It still works today but is deprecated, with removal planned for a later release. Plan the migration now and check the official release notes for the exact schedule.

The Kyverno project maintains a public policy library covering Pod Security Standards, best practices and many compliance needs. It is a good starting point and a great way to learn how experienced authors structure rules.

Yes. The command-line tool can apply policies to manifest files in a developer’s pipeline, so violations are found during code review instead of at deployment time.

Yes. Policies are ordinary resources, so GitOps tools can apply and manage them like anything else. This is the recommended way to handle policies at scale.

It is better not to. With the newer policy types, each job has its own dedicated type, and small single-purpose policies are easier to test, own and retire.

Kyverno turns the rules your organization cares about into living, testable, versioned resources that the cluster itself enforces. It sits at the admission stage of the Kubernetes request path, where it can check, change and create resources, verify the software supply chain, clean up clutter and report on everything it sees. Its recent move to CEL-based policy types brings it in line with Kubernetes’ own direction, and its graduation within the CNCF signals maturity and long-term stability. The technology is only half of the story. Success also depends on careful rollouts, clear messages, narrow matching, healthy replicas, honest exceptions and steady communication with the teams you are trying to help.