GitHub
nirmata/kyverno-zero-trust (opens in a new tab)
Every policy in the eBook, grouped by CISA pillar, with tests.
eBook
Zero Trust for Kubernetes with Kyverno
Kubernetes trusts by default. Any Pod can reach any other Pod, every Pod gets an API token, and any image can run. This guide removes that implicit trust with policy as code, mapped to NIST SP 800-207 and the CISA Zero Trust Maturity Model.
Security leaders
Chapters 1, 2, 10, 13
The case, the frameworks, the roadmap and the 90-day plan.
Architects
Add chapters 3 and 9
Kyverno as the policy decision point and the reference architecture.
Platform & security engineers
Chapters 3–8, with the repo
Every policy, with tests and an audit-first install profile.
Why Kubernetes needs Zero Trust
Six defaults that let one compromised Pod reach the rest
Each one has existed since Kubernetes 1.0. Each one maps to a chapter that closes it.
| Default behavior | Risk | Fixed in |
|---|---|---|
| Any Pod can reach any other Pod | An attacker moves laterally from one compromised Pod. | Chapter 4 |
| Every Pod mounts a service account token | A stolen token lets an attacker call the Kubernetes API. | Chapter 5 |
| RBAC allows wildcards and cluster-admin bindings | One over-privileged account controls the cluster. | Chapter 5 |
| The cluster runs any image from any registry | Tampered or vulnerable images run in production. | Chapter 6 |
| Pods can run as root or privileged | A container escape gives access to the node. | Chapter 6 |
| Exceptions to policy never expire | Temporary bypasses become permanent holes. | Chapter 7 |
What's inside
Five control areas, one policy layer
Each chapter gives you a tested Kyverno policy, shows how to check that it works, and names the other components that complete the control.
Default deny, generated in every namespace
Segmentation that depends on a human setting a label correctly isn't segmentation. Derive it from a boundary the platform team controls.
- Reject namespaces that don't declare a
workspaceandtier. - Copy those labels onto every Pod, so developers can't get them wrong.
- Generate default-deny, DNS, workspace-isolation and tier rules from the labels.
Policies in the repo
generate-default-denygenerate-workspace-network-policygenerate-backend-tier-policyrequire-workspace-labelsadd-workload-labelsprotect-segmentation-labelsgenerate-strict-mtls
Also needed: a CNI plugin that enforces NetworkPolicy (Cilium or Calico), and a service mesh for mTLS.
No standing admin, no stray tokens
Grant access per session instead of standing privileges, and make every grant narrow and time-bound.
- Block wildcard RBAC, cluster-admin bindings and escalation verbs.
- Stop automounting service account tokens, and keep workloads off the default service account.
- Replace standing admin access with just-in-time RoleBindings that expire.
Policies in the repo
restrict-wildcard-rbacrestrict-cluster-admin-bindingrestrict-escalation-verbsdisable-token-automountdisallow-default-serviceaccountrestrict-jit-labelsgenerate-jit-rolebinding
Also needed: your identity provider and API server RBAC authenticate and authorize first. Kyverno adds context-aware checks at admission.
Exceptions that are scoped, approved and expire
A permanent exception is standing trust. Treat it like any other access grant.
- Accept PolicyExceptions only from one namespace,
kyverno-exceptions. - Require a named owner, a ticket and a time to live. The cleanup controller removes expired exceptions.
- Enforce a compensating control for as long as the exception is active.
Policies in the repo
govern-policy-exceptionsnode-exporter-host-networknode-exporter-compensating-controls
Set this up first. Teams need a safe way to request exceptions before you enforce anything.
Admission is a gate. Zero Trust keeps checking.
Background scans re-check existing resources, including ones created before a policy existed, and write standard policy reports.
- Keep background scanning on, and move policies from Audit to Deny one pillar at a time.
- Send policy reports and metrics to your dashboards and SIEM.
- Track posture against the baseline you recorded on day 1.
Tools
kubectl get policyreports -APolicy Reporterkyverno test
Also needed: API server audit logs for who did what, and a runtime security tool for what processes do after they start (Chapter 12).
Maturity check
Where does your cluster sit on the CISA Zero Trust Maturity Model?
Pick the stage that matches each pillar today. You'll get your next step and the chapter that covers it.
NetworksChapter 4
Flat Pod network.
IdentityChapter 5
Shared admin accounts and standing cluster-admin.
Applications & WorkloadsChapter 6
Any image, any settings.
GovernanceChapter 7
Exceptions by email, and they never expire.
Visibility & AnalyticsChapter 8
No policy data.
Your overall stage
Traditional
Implicit trust everywhere. The audit profile shows you exactly where, without blocking anything.
Your next steps
Why now
None of these attacks used a novel technique
Each one worked because trust was implicit somewhere. The eBook maps eight documented incidents to the control that would have stopped or contained them.
March 2025
IngressNightmare
An admission webhook accepted unauthenticated requests and ran with a service account that could read every Secret. More than 6,500 clusters were found exposed.
Restrict webhook access, scope the service account · Ch 4, 5
Through Nov 2025
ShadowRay 2.0
The Ray dashboard API has no authentication by default and was exposed to the internet, then used to mine crypto, steal models and spread to other nodes.
Default-deny ingress and egress, tier segmentation · Ch 4
November 2025
runc container escapes
Containers with custom mount configurations could redirect writes to host paths and gain root on the node.
Restricted Pod Security Standard · Ch 6
March 2026
LiteLLM supply chain
A compromised CI credential published a backdoored LLM gateway that harvested cloud and Kubernetes credentials and deployed privileged Pods.
Verify signatures, block privileged Pods, restrict egress · Ch 4–6
Companion repository
See where you stand without blocking a single request
The audit profile installs every core policy in Audit mode, so it reports violations without blocking anything.
bash
# 1. Get the policies git clone https://github.com/nirmata/kyverno-zero-trust cd kyverno-zero-trust # 2. Install every core policy in Audit mode kubectl apply -k deploy/audit # 3. Review what would have been blocked kubectl get policyreports -A
Each policy has a README, Kyverno CLI tests and an end-to-end test for a local kind cluster. Browse the repo → (opens in a new tab)
Days 1–30
See where you stand
- Apply the audit profile in test, then production.
- Generate default deny and DNS rules for new namespaces.
- Set up the exception namespace and approvers.
- Record baseline metrics.
Days 31–60
Enforce the basics
- Fix audit failures, or cover them with governed exceptions.
- Move Pod security, registry and RBAC policies to Deny.
- Roll default deny into existing namespaces, one team at a time.
- Add
kyverno testto CI and start signing images.
Days 61–90
Remove standing trust
- Enforce image signature verification.
- Replace standing admin access with JIT RoleBindings.
- Require compensating controls for every exception.
- Turn on mTLS and name-based egress for sensitive namespaces.
From one cluster to a fleet
The policies are open source. Operating them everywhere is the hard part.
Nirmata Control Hub authors, delivers and reports on Kyverno policies and exceptions across every cluster and team, so you can track maturity by pillar fleet-wide. Nirmata Enterprise for Kyverno is a hardened, supported build of the same engine, with CVE fixes backported to every supported release.
Keep going
Whitepaper
The Kyverno Operator's Playbook
Harden, test, patch and upgrade the engine these policies run on.
Free tool
Scan manifests in CI
Run the same policies in your pipeline, before a manifest reaches a cluster.
Talk to the team that created Kyverno
Mapping Kubernetes controls to NIST and CISA for an audit, moving from Audit to Enforce, or rolling Zero Trust out across a fleet? Talk to the maintainers.