Summary
Kyverno has a missing authorization issue that can let authors of namespaced Policies cause resources from other namespaces to be copied into their own namespace. If a triggering ConfigMap is annotated and the policy templates a cross-namespace clone target, the background controller may disclose sensitive ConfigMap data across tenant boundaries.
Kyverno has a missing authorization issue that can let authors of namespaced Policies cause resources from other namespaces to be copied into their own namespace. If a triggering ConfigMap is annotated and the policy templates a cross-namespace clone target, the background controller may disclose sensitive ConfigMap data across tenant boundaries.
Affected context
The issue affects Kyverno deployments where namespaced Policy authors can use templated generate.clone or cloneList namespace values. Risk depends on whether a policy can cause the background controller to copy resources from namespaces beyond the policy author's authorized scope.
The issue affects Kyverno deployments where namespaced Policy authors can use templated generate.clone or cloneList namespace values. Risk depends on whether a policy can cause the background controller to copy resources from namespaces beyond the policy author's authorized scope.
Exploit preconditions
- Attack surface: Namespaced Kyverno Policies that generate cloned resources
- Required access: Ability to author or modify a namespaced Policy and annotate a ConfigMap that triggers it
- Trigger point: Background-controller processing of the triggering ConfigMap and the policy's clone configuration
- Why exploitation is possible: The requested source namespace may not be adequately checked against the policy author's authorization scope
- Attack surface: Namespaced Kyverno Policies that generate cloned resources
- Required access: Ability to author or modify a namespaced Policy and annotate a ConfigMap that triggers it
- Trigger point: Background-controller processing of the triggering ConfigMap and the policy's clone configuration
- Why exploitation is possible: The requested source namespace may not be adequately checked against the policy author's authorization scope
Why this happens
The underlying issue is an authorization check that does not sufficiently constrain cross-namespace resource cloning. When policy-controlled namespace values influence the clone source without verifying that the policy author is permitted to access that namespace, a namespaced policy can cross an intended tenant boundary. This is a missing authorization weakness mapped to CWE-862.
The underlying issue is an authorization check that does not sufficiently constrain cross-namespace resource cloning. When policy-controlled namespace values influence the clone source without verifying that the policy author is permitted to access that namespace, a namespaced policy can cross an intended tenant boundary. This is a missing authorization weakness mapped to CWE-862.
Potential impact
- Sensitive ConfigMap data may be disclosed to an unauthorized namespace
- Tenant isolation could be weakened
- Exposed configuration data could support further compromise, depending on its contents and how it is used
- Sensitive ConfigMap data may be disclosed to an unauthorized namespace
- Tenant isolation could be weakened
- Exposed configuration data could support further compromise, depending on its contents and how it is used
General mitigation guidance
Defensive patterns focus on enforcing authorization at the point where clone sources are resolved and accessed.
- Restrict clone operations to the policy author's authorized namespace scope by default
- Validate templated namespace values against explicit authorization rules
- Use secure-by-default policy controls that deny cross-namespace cloning unless explicitly permitted
- Reduce trust in user-controlled policy fields and triggering resource annotations
- Apply least privilege to the background controller and limit its access to sensitive resources
Defensive patterns focus on enforcing authorization at the point where clone sources are resolved and accessed.
- Restrict clone operations to the policy author's authorized namespace scope by default
- Validate templated namespace values against explicit authorization rules
- Use secure-by-default policy controls that deny cross-namespace cloning unless explicitly permitted
- Reduce trust in user-controlled policy fields and triggering resource annotations
- Apply least privilege to the background controller and limit its access to sensitive resources
How teams detect issues like this
Review policy handling and controller code for clone operations whose source namespace is derived from templates or other user-controlled values. Static analysis and code review can look for resource lookups that are not preceded by namespace-scoped authorization checks. Admission policies can also enforce restrictions on cross-namespace clone sources, and automated review tools can help flag policies that broaden namespace access.
Review policy handling and controller code for clone operations whose source namespace is derived from templates or other user-controlled values. Static analysis and code review can look for resource lookups that are not preceded by namespace-scoped authorization checks. Admission policies can also enforce restrictions on cross-namespace clone sources, and automated review tools can help flag policies that broaden namespace access.
