Kyverno SSRF breaks namespace isolation and exposes cloud credentials

At a glance

What this is: This is a critical Kyverno SSRF issue that lets namespace-scoped policies trigger outbound HTTP from the admission controller and bypass namespace isolation.

Why it matters: It matters because IAM and platform teams must treat policy engines as privileged network actors, not just in-cluster validation tools, when evaluating NHI exposure and cloud credential risk.

By the numbers:

• A critical SSRF vulnerability affects Kyverno versions 1.16.0 and later.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Orca Security's analysis of the Kyverno SSRF and namespace isolation break

Context

Kyverno is a Kubernetes policy engine, but in this case it behaves like a privileged network intermediary. The problem is not the policy author’s namespace rights alone. The problem is that a namespaced policy can cause the Kyverno admission controller to make outbound HTTP requests from a trusted cluster pod, which turns a delegated control plane action into a cross-boundary data access path.

That breaks a common identity and platform assumption: a namespace-scoped actor should remain bounded by namespace-scoped effects. Once the policy engine can reach internal services or metadata endpoints on behalf of that actor, Kubernetes RBAC no longer describes the full blast radius. This is a workload identity and policy governance issue as much as it is a software flaw.

The article’s PoC shows why this is operationally serious. A namespace admin with no access to kube-system still managed to exfiltrate data through the admission controller, which is an atypical but realistic failure mode for clusters that allow user-defined policy logic with network side effects.

Key questions

Q: What breaks when namespace-scoped policies can trigger outbound HTTP from a controller?

A: Namespace scoping stops describing the real blast radius. A user with limited policy rights can cause a privileged controller to reach internal services or metadata endpoints, so the effective access path is controlled by the controller’s network position, not the author’s RBAC permissions. That creates a cross-boundary data access problem.

Q: Why do admission controllers make SSRF more dangerous than ordinary application SSRF?

A: Admission controllers run inside the trust boundary of the cluster and often have broad egress. If they evaluate user-controlled expressions that can initiate requests, the attacker can weaponise trusted infrastructure to reach internal services or cloud metadata. That makes SSRF an authorization and identity-governance issue, not only an application bug.

Q: How do security teams know whether a policy engine can be abused for cloud credential theft?

A: Look for any feature that lets policy logic call external URLs, then test whether the controller can reach link-local metadata addresses or internal service DNS names. If the answer is yes, SSRF can become credential exposure. The relevant signal is controller egress, not just policy author permissions.

Q: Who is accountable when a delegated policy engine leaks internal or cloud data?

A: Accountability sits with the team that owns the controller, the platform network rules, and the delegation model together. Namespace admins may author the policy, but they do not control the runtime privilege of the admission controller. That is why control-plane governance, network policy, and RBAC must be reviewed as one boundary.

Technical breakdown

How CEL http functions turn policy evaluation into SSRF

Kyverno added CEL-based policy logic with http.Get() and http.Post() helpers. The vulnerability appears because the HTTP helper is not namespace-aware, while the resource helper enforces namespace context. That means the policy compiler can allow user-influenced expressions to initiate network calls without checking whether the destination is internal, external, or link-local. In security terms, this is SSRF inside an admission control path, not a simple validation bug.

Practical implication: review any policy language feature that can initiate outbound requests from a privileged controller.

Why RBAC does not stop outbound requests from the admission controller

Kubernetes RBAC governs API actions, not raw network traffic. When Kyverno evaluates a namespaced policy, the HTTP request originates from the controller pod, so the request inherits the pod’s network reach rather than the author’s namespace permissions. That creates a control-plane mismatch: the person creating the policy is constrained, but the infrastructure component executing it is not. The result is a cross-namespace trust breakout.

Practical implication: treat controller egress as part of authorization design, not just network hygiene.

Cloud metadata endpoints make SSRF a credential theft problem

Cloud instance metadata services are intentionally accessible from workloads that can reach them, because they provide temporary credentials and configuration to the node or pod. In a Kubernetes SSRF scenario, that means the attacker does not need to steal a password or token first. Reaching 169.254.169.254 or its cloud-specific equivalents can be enough to obtain short-lived cloud credentials, which then expand the incident beyond the cluster boundary.

Practical implication: block metadata access from controllers that never need it, and assume SSRF can become cloud credential exposure.

Threat narrative

Attacker objective: The attacker wants to turn delegated namespace policy rights into access to internal cluster data and cloud credentials without needing kube-system permissions.

1. Entry occurs when an attacker with namespace-scoped policy creation rights submits a malicious namespaced Kyverno policy containing an http.Get() call.
2. Credential access occurs when the admission controller pod follows that request to an internal service or metadata endpoint and returns the response content through the policy evaluation path.
3. Impact occurs when the attacker uses the reflected data to exfiltrate internal secrets or cloud credentials, breaking namespace isolation and potentially extending access into cloud resources.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• New York Times breach — New York Times source code and credentials exposed via GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Namespace-scoped policy is not the same thing as namespace-scoped effect: this breach worked because the governance model assumed delegated policy authors could only influence their own namespace. That assumption failed when policy execution moved into the Kyverno admission controller pod, which had broader network reach than the author. The implication is that platform teams must stop treating policy delegation as a purely logical boundary and recognise the controller’s egress as part of the trust model.

Cross-namespace data access through a control-plane helper is a governance gap, not just a coding flaw: the vulnerable pattern is a privileged component executing user-influenced network calls without destination constraints. That breaks the premise that validation logic is a read-only gate. The practitioner takeaway is that admission controllers, webhook servers, and policy engines need explicit egress governance when they accept user-defined logic.

Cloud metadata exposure is the named failure mode this breach illustrates: a controller that can reach metadata endpoints turns SSRF into temporary cloud credential theft. This is not an abstract SSRF lesson. It is a concrete example of privileged workload reach defeating identity boundaries, especially where workload identity and cloud IAM are linked through the node or pod network path.

Admission controllers as SSRF targets should now be treated as a category, not a one-off bug: any engine that combines privileged network position, user-controlled expressions, and reflected output can become a data exfiltration path. That should change how security teams assess policy-as-code, because the exposure is created by where the code runs, not only by who authored it.

Secret visibility and controller egress are now joined governance problems: if an admission controller can fetch internal data, then hidden service credentials, tokens, and metadata become reachable from places the original operator never intended. The implication is that access reviews and network policy reviews need to be evaluated together for control-plane workloads.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• That visibility gap is why the 52 NHI Breaches Analysis is the right next step for teams mapping controller and credential exposure paths.

What this signals

Control-plane egress is now part of NHI governance: policy engines, admission controllers, and webhook services behave like privileged non-human identities when they can initiate outbound requests on behalf of delegated users. Teams that still separate policy review from egress review will miss the path by which namespace-scoped actions become cluster-scoped exposure.

With 97% of NHIs carrying excessive privileges in our research, the Kyverno pattern is familiar: the dangerous part is rarely the intended function, it is the runtime reach attached to it. Security teams should map where controllers can call out, where their responses are reflected, and whether those destinations include internal services or metadata endpoints.

Control-plane SSRF debt: this is the hidden risk created when privileged infrastructure is allowed to execute user-controlled logic with network side effects. Teams should pair policy-as-code reviews with egress restriction, and they should use the OWASP Non-Human Identity Top 10 to frame controller risk as an identity problem, not just a Kubernetes configuration issue.

For practitioners

• Review policy engines for outbound request primitives Inventory admission controllers and policy systems that expose HTTP helpers, external data lookups, or templated network calls. Prioritise any component that runs with cluster-level network reach and accepts namespace-delegated input.
• Restrict egress from Kyverno and similar controllers Apply network policy, firewall rules, or cloud-level controls so controller pods can only reach the Kubernetes API server and explicitly approved destinations. Block metadata endpoints such as 169.254.169.254 unless a workload has a documented need.
• Separate namespace delegation from network privilege Revisit any assumption that namespace-scoped policy authorisation is safe if the controller executing it can leave the namespace. Where user-defined logic can trigger HTTP, treat the controller as a privileged non-human identity with its own authorization boundary.
• Search for policies that call http.Get or http.Post Query Kyverno policies for HTTP helpers and review whether those policies are namespaced or cluster-scoped. Focus on expressions that could reach internal services, cloud metadata, or other namespaces through reflected responses.

Key takeaways

• Kyverno’s SSRF flaw shows that delegated namespace rights can still produce cluster-wide impact when a privileged controller performs the network call.
• The evidence is concrete: namespace-scoped policy creation can trigger internal service access and even cloud credential exposure through metadata endpoints.
• The control that matters most is controller egress governance, because RBAC alone does not limit what a privileged admission path can reach.

Key terms

• Admission Controller SSRF: An admission controller SSRF occurs when a cluster component that evaluates requests before they are saved can be tricked into making outbound network calls. In practice, the controller’s privileged network position becomes the attacker’s path to internal services or metadata endpoints.
• Namespace Isolation: Namespace isolation is the expectation that users or policies restricted to one Kubernetes namespace cannot affect resources or data outside that namespace. It fails when a shared controller executes delegated logic with broader runtime privileges than the author of the request.
• Metadata Endpoint Exposure: Metadata endpoint exposure is the risk that a workload can reach a cloud provider’s internal credential service and retrieve temporary identity material. If an attacker can induce a privileged pod to call that endpoint, cloud access can be obtained without stealing a traditional secret.

Deepen your knowledge

Kyverno SSRF, controller egress, and namespace delegation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing privileged Kubernetes components with user-defined logic, it is worth exploring.

This post draws on content published by Orca Security: Kyverno SSRF vulnerability in policy evaluation and namespace isolation. Read the original.