Summary
A namespace-isolation flaw in Kyverno exposes cluster-scoped GlobalContextEntry data to namespaced policies that should not be able to read it. A tenant able to create an affected policy in its own namespace may retrieve cached information from other namespaces when the globalContext CEL library is evaluated.
Affected context
The issue affects Kyverno policy environments where the globalcontext.Lib CEL library is available to namespaced policy resources without being constrained to the policy's namespace. It becomes risky when tenants can create namespaced validating, mutating, deleting, generating, or image-validating policies and GlobalContextEntry objects contain data collected from namespaces outside the tenant's authorized RBAC scope.
Exploit preconditions
- Attack surface: Kyverno CEL policy evaluation for namespaced policy resources
- Required access: Permission to create or modify an affected namespaced policy in a tenant-controlled namespace
- Trigger point: Evaluation of a policy expression that invokes the global context lookup library
- Why exploitation is possible: The library accesses cluster-scoped cached entries without applying the policy namespace or equivalent tenant authorization boundary
Why this happens
The underlying flaw is an authorization-boundary failure in the registration of a shared CEL library. Unlike related libraries that receive the policy namespace, the global context library is exposed without namespace confinement, allowing a namespaced policy to resolve cluster-scoped cached data.
This behavior maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor because data is returned to a policy author who may lack permission to read the source resources or namespaces. The insecure pattern is treating a cluster-wide cache as universally readable from tenant-controlled policy expressions.
Potential impact
- Tenant-controlled policies may disclose cached data from other namespaces
- Sensitive configuration, metadata, or resource-derived values could be exposed
- Cross-namespace isolation guarantees may be weakened
- Disclosed information could support later privilege escalation or targeted attacks
General mitigation guidance
Mitigation generally focuses on enforcing authorization and namespace boundaries at the point where CEL libraries access shared state.
Common defensive patterns include:
- Binding global-context lookups to the requesting policy's namespace and identity
- Applying RBAC checks before returning cluster-scoped or cross-namespace data
- Exposing only explicitly allowlisted fields through tenant-controlled policy environments
- Separating tenant policy execution from cluster-administrator policy capabilities
- Minimizing sensitive data stored in shared caches and applying least-privilege access to their sources
- Rejecting or restricting policy expressions that cross approved namespace boundaries
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis of CEL library registration and evaluator construction
- Code review checks for namespace, tenant, or subject context being omitted from shared data accessors
- Tests that create namespaced policies and verify they cannot observe entries from unauthorized namespaces
- Authorization policy checks covering GlobalContextEntry reads and policy expression capabilities
- Runtime audit monitoring for cross-namespace policy evaluation and unexpected access to global context data
Automated security review tools may help identify unscoped accessors, but authorization-boundary tests should validate the deployed behavior.
