Summary
Kyverno's cleanup controller can process a namespaced CleanupPolicy with context entries that bypass namespace confinement. A namespace administrator may use this behavior to read Secrets in other namespaces or modify validating webhook configurations through the controller's ServiceAccount.
Kyverno's cleanup controller can process a namespaced CleanupPolicy with context entries that bypass namespace confinement. A namespace administrator may use this behavior to read Secrets in other namespaces or modify validating webhook configurations through the controller's ServiceAccount.
Affected context
The issue affects Kyverno cleanup-controller deployments in the stated release range when the controller builds its context loader with a nil policy. A namespaced CleanupPolicy containing apiCall or globalReference context entries may then be evaluated without the intended namespace authorization checks.
The issue affects Kyverno cleanup-controller deployments in the stated release range when the controller builds its context loader with a nil policy. A namespaced CleanupPolicy containing apiCall or globalReference context entries may then be evaluated without the intended namespace authorization checks.
Exploit preconditions
- Attack surface: Kyverno's cleanup-policy processing
- Required access: Ability to create a namespaced CleanupPolicy, such as namespace-admin access
- Trigger point: The cleanup controller evaluates the policy's context entries
- Why exploitation is possible: A nil policy in the context loader can cause authorization checks to be bypassed, allowing operations under the cleanup controller's ServiceAccount beyond the namespace boundary
- Attack surface: Kyverno's cleanup-policy processing
- Required access: Ability to create a namespaced CleanupPolicy, such as namespace-admin access
- Trigger point: The cleanup controller evaluates the policy's context entries
- Why exploitation is possible: A nil policy in the context loader can cause authorization checks to be bypassed, allowing operations under the cleanup controller's ServiceAccount beyond the namespace boundary
Why this happens
The cleanup controller constructs a context loader without the policy information needed to enforce the intended authorization scope. As a result, context entries such as apiCall or globalReference may be processed without adequate authorization checks. This is an authorization enforcement failure mapped to CWE-863: Incorrect Authorization: access is granted without correctly verifying whether the requesting policy is permitted to perform the operation.
The cleanup controller constructs a context loader without the policy information needed to enforce the intended authorization scope. As a result, context entries such as apiCall or globalReference may be processed without adequate authorization checks. This is an authorization enforcement failure mapped to CWE-863: Incorrect Authorization: access is granted without correctly verifying whether the requesting policy is permitted to perform the operation.
Potential impact
- A namespace administrator may be able to read Secrets from other namespaces.
- An attacker could modify validating webhook configurations using the cleanup controller's ServiceAccount.
- Security controls enforced by validating webhooks could be weakened or disrupted.
- The controller's permissions could enable further unauthorized actions, depending on its configuration.
- A namespace administrator may be able to read Secrets from other namespaces.
- An attacker could modify validating webhook configurations using the cleanup controller's ServiceAccount.
- Security controls enforced by validating webhooks could be weakened or disrupted.
- The controller's permissions could enable further unauthorized actions, depending on its configuration.
General mitigation guidance
Defensive approaches include ensuring authorization decisions are made with the correct policy and namespace context before resolving references or performing API calls. Restrict context features to explicitly authorized resources, apply least-privilege permissions to controller ServiceAccounts, and limit who can create or modify cleanup policies. Where possible, prefer secure-by-default configuration and reduce reliance on user-controlled references or inputs.
Defensive approaches include ensuring authorization decisions are made with the correct policy and namespace context before resolving references or performing API calls. Restrict context features to explicitly authorized resources, apply least-privilege permissions to controller ServiceAccounts, and limit who can create or modify cleanup policies. Where possible, prefer secure-by-default configuration and reduce reliance on user-controlled references or inputs.
How teams detect issues like this
Review cleanup-controller code and configuration for context loaders created without policy or namespace authorization context. Use static analysis and code review to identify API calls or reference resolution that occur before access checks. Monitor policy creation and changes, cross-namespace Secret access, and modifications to validating webhook configurations; enforce admission policies that restrict these operations to trusted identities.
Review cleanup-controller code and configuration for context loaders created without policy or namespace authorization context. Use static analysis and code review to identify API calls or reference resolution that occur before access checks. Monitor policy creation and changes, cross-namespace Secret access, and modifications to validating webhook configurations; enforce admission policies that restrict these operations to trusted identities.
