How Chase UK Made Kubernetes Audit-Ready with Kyverno Policy as Code
Chase UK made Kubernetes audit-ready by replacing a manual compliance process with Kyverno policies enforced in every cluster from the day it is built. Policy reports feed one Grafana dashboard for developers, security teams and auditors. The bank has grown from 4 policies to 46 across 50 clusters, with average admission latency under 20 milliseconds.
Nischay Goyal, Senior Lead Platform Engineer at Chase UK (JPMorganChase), presented the journey with Kyverno maintainer Jim Bugwadia at KubeCon + CloudNativeCon Europe 2026 in Amsterdam. This post covers the problem, the stack, the numbers and the lessons from that talk. The recording is below.
What made compliance hard at Chase UK?
Chase UK launched in September 2021 and now has more than 2.5 million customers and over £20 billion in deposits. The platform behind it runs hundreds of services on about 50 clusters and 2,000 nodes, and independent backend teams ship to it every day.
In Nischay’s words, the team realised it “didn’t have a compliance system, we actually had a compliance process”. When security or audit teams asked how the environment was configured, the platform team answered with quarterly reports, spreadsheets and the output of kubectl commands. Requirements arrived ad hoc as the bank grew, the work was manual, and no two reports looked the same.
| Before | Problem |
|---|---|
| Reactive compliance | Questions answered only when security or audit asked |
| Manual auditing | Spreadsheets and kubectl output, assembled by hand |
| No standard reporting | Each stakeholder got a different, inconsistent answer |
What did audit-ready need to mean?
The team wrote down six requirements before choosing a tool:
- Standardised resource configuration. Any pod picked from thousands should look the same as the baseline.
- Enforced guardrails, not guidelines. Recommendations get ignored in practice.
- Policy defined once, applied everywhere across the whole estate.
- Developer-friendly. Security must not become a bottleneck.
- Auditor-ready reporting for developers, team leads, platform operators, security, audit and regulatory teams.
- Scales as clusters and policies grow.
They evaluated four options: the OPA Gatekeeper deployment they already had, building custom admission webhooks in-house, Kyverno, and other policy engines.
Why OPA Gatekeeper didn’t stick
Gatekeeper had been in place since before launch. Over roughly four years it produced four policies in production. Rego expertise was scarce in 2022 and 2023, the engineers who had written those policies had left the team, and every change depended on a small group of platform and security engineers. Without reporting, there was no developer ownership of failing resources either.
Chase UK chose Kyverno for five reasons:
| Reason | Why it mattered |
|---|---|
| Kubernetes-native (YAML and CRDs) | No new language to learn; anyone who writes manifests can read a policy |
| No Rego learning curve | Policies stopped depending on one or two specialists |
| Built-in reporting | Stakeholders could see results without platform engineers running queries |
| Enforce, Audit and Warn modes | Each policy rolls out at the right strictness |
| Policy exceptions as first-class resources | Edge cases get a defined path instead of a custom process |
On exceptions, Nischay put it this way: in banking, “100% compliance” doesn’t mean every workload meets every policy. It means 100% of the risk is managed. If 99% of workloads comply, the remaining 1% needs a documented, reviewable exception, not a back door.
The audit-ready Kubernetes stack
The stack is deliberately simple:
| Layer | Tool | Role |
|---|---|---|
| Enforcement | Kyverno admission controller | Part of the base cluster definition, present in every cluster from the moment it is built |
| Results | Kyverno policy reports | Pass, fail and skip results per resource, policy and rule |
| Metrics | Prometheus, Thanos | Collect and aggregate results across clusters |
| Reporting | Grafana | One dashboard for every audience |
One dashboard, filtered per audience
Chase UK runs a single Grafana dashboard with filters for policy category, namespace and policy:
- Security engineers filter by category. Pod Security Standards (restricted) shows no failures across all clusters, because every workload must pass it.
- Team leads filter by namespace to see their own workloads.
- Platform engineers filter by a single policy before rolling it out. If 80% or 95% of workloads already pass, they know how much work the policy will create for teams before it is enforced.
- Developers use a violations panel that lists the cluster, namespace, resource kind and name, policy, rule and category in one row.
The violations panel exists because, as Nischay noted, fixing a problem usually takes less time than gathering the information needed to fix it. When Pod Security Policies were deprecated, the same data showed that 99% of workloads had relied on PSP mutation to add settings, so the team replaced it with a Kyverno policy rather than asking every developer to change their manifests.
Admission latency
Kyverno has run in Chase UK’s clusters for almost three years. Average admission latency across the estate is under 20 milliseconds. The general guideline is under 100 milliseconds: every workload change passes through admission, so a slow controller backs up the whole cluster.
From 4 policies to 46
| Year | Policies | Focus |
|---|---|---|
| 2021 | 4 | Chase UK launches; policies on OPA Gatekeeper |
| 2023 | 6 | Migration to Kyverno; engineering practices; Istio |
| 2024 | 30 | Pod Security Policy replacement; mutation policies |
| 2025 | 44 | Networking |
| 2026 | 46 | Multi-region compliance |
| 2027 (planned) | Unified time-bound policy exceptions |
The move started with an audit finding in 2023. Nischay took the problem from research to production in a month, which he stressed is fast for a bank. The team migrated the four existing policies and decommissioned OPA Gatekeeper the same year.
The bigger change was cultural. Policies are no longer written by one team. Any developer or security engineer can open a pull request with a new policy for review, instead of filing a ticket and waiting for the platform team. Teams now think about ownership labels, reliability and protection when they design a service, not after an audit.
What Chase UK got from it
Nischay estimates roughly 7–8 months of engineering effort saved, split across four areas:
| Area | Share of savings |
|---|---|
| Engineering best practices | 30% |
| Self-service audits | 25% |
| Preventing misconfigurations | 25% |
| Automation and cleanup | 20% |
Two examples from the talk: before each Kubernetes upgrade, a policy shows which applications still use deprecated APIs, instead of someone reading release notes and searching manifests; and cleanup policies removed dangling resources.
And the result that mattered most: the auditors were happy, which Nischay called one of the hardest KPIs to meet.
Three lessons for your own rollout
- Test policies in CI. One policy can affect a whole cluster. Chase UK wasn’t testing policies at first; now every policy ships with test cases. The Kyverno CLI runs them in a pipeline.
- Start in enforce mode when you can. A policy that starts in audit mode can take ages to reach enforcement. Enforcing from day one means new resources are always compliant. Write rules so they can be enforced early: a policy on Pods sees every new Pod at admission, while a policy on Deployments only sees a Deployment when it is redeployed.
- Keep scope and exceptions apart. A policy’s match rules skip resources outside its scope, and an exception also produces a skip. Auditors asked why there were so many exceptions when the team had very few; most were scope skips. Make the two easy to tell apart in your reports.
Watch the talk
Jim covers Kyverno’s five policy types (validating, image validating, mutating, generating and deleting), exception management and OpenReports. Nischay walks through the dashboard and the journey.
Applying the pattern
The same pattern shows up in regulated platforms elsewhere. Razorpay applies it to RBI’s Payment Aggregator rules across 7,000+ nodes. If you are still on Gatekeeper, our Kyverno vs OPA Gatekeeper comparison and the OPA to Kyverno migration guide cover the move. For exceptions, see managing policy exceptions across clusters. To map policies to a specific standard and produce evidence for auditors, read about continuous compliance with Nirmata.
Frequently asked questions
What does audit-ready Kubernetes mean?
It means compliance evidence exists at all times, not only when an auditor asks. Every cluster enforces the same policies from the moment it is built, every violation and exception is recorded, and security, audit and engineering teams can each see the current state on a dashboard instead of waiting for a quarterly report or a spreadsheet.
Why did Chase UK move from OPA Gatekeeper to Kyverno?
After about four years on OPA Gatekeeper, Chase UK had four policies in production. Rego expertise was scarce, the engineers who wrote those policies had moved on, and there was no reporting to give developers ownership of their resources. Kyverno policies are Kubernetes YAML with built-in reporting and exceptions, and the team migrated the four policies and decommissioned Gatekeeper in 2023.
Does Kyverno slow down the Kubernetes API server?
Chase UK reports an average admission latency under 20 milliseconds across its estate, after almost three years in production. The usual guidance is to keep admission latency under 100 milliseconds, because a slow admission controller delays every workload change in the cluster.
Should a new Kyverno policy start in audit mode or enforce mode?
Chase UK's advice is to start in enforce mode wherever you can. A policy left in audit mode tends to stay there. Enforcing from day one means everything new entering the cluster is compliant, so the count of non-compliant resources can only go down.
How do policy exceptions work in an audit?
In Kyverno, a PolicyException is a Kubernetes resource, so it is reviewed in Git and visible in reports like any other change. Chase UK found one catch: resources skipped because they are outside a policy's scope can also show up as skipped results, which auditors may read as exceptions. Keep scope rules and exceptions clearly separated.