Summary
Kyverno's Generation Handler can treat a ConfigMap with spoofed internal labels as a trigger for a synchronized generate policy. A user who can create or update a ConfigMap may be able to cause sensitive Secrets to be copied from a restricted namespace into a namespace they control.
Kyverno's Generation Handler can treat a ConfigMap with spoofed internal labels as a trigger for a synchronized generate policy. A user who can create or update a ConfigMap may be able to cause sensitive Secrets to be copied from a restricted namespace into a namespace they control.
Affected context
The issue affects Kyverno deployments where the Generation Handler processes ConfigMaps for synchronized generate policies. It becomes risky when a user with create or update permissions can supply labels that the handler trusts as indicators of Kyverno-managed resources and policy triggers.
The issue affects Kyverno deployments where the Generation Handler processes ConfigMaps for synchronized generate policies. It becomes risky when a user with create or update permissions can supply labels that the handler trusts as indicators of Kyverno-managed resources and policy triggers.
Exploit preconditions
- Attack surface: Kyverno's Generation Handler and ConfigMaps it processes
- Required access: Permission to create or update a ConfigMap that reaches the handler
- Trigger point: The handler evaluates labels on the ConfigMap for a synchronized generate policy
- Why exploitation is possible: User-controlled labels can be made to resemble internal Kyverno metadata, potentially causing the handler to generate a Secret in the user's namespace
- Attack surface: Kyverno's Generation Handler and ConfigMaps it processes
- Required access: Permission to create or update a ConfigMap that reaches the handler
- Trigger point: The handler evaluates labels on the ConfigMap for a synchronized generate policy
- Why exploitation is possible: User-controlled labels can be made to resemble internal Kyverno metadata, potentially causing the handler to generate a Secret in the user's namespace
Why this happens
The authorization check relies on metadata labels that a user with ConfigMap write access may be able to set or alter. When those labels are trusted as proof that a resource is an authorized Kyverno trigger, a user can influence generation without the intended authorization. This is an authorization bypass through a user-controlled key, mapping to CWE-639.
The authorization check relies on metadata labels that a user with ConfigMap write access may be able to set or alter. When those labels are trusted as proof that a resource is an authorized Kyverno trigger, a user can influence generation without the intended authorization. This is an authorization bypass through a user-controlled key, mapping to CWE-639.
Potential impact
- Sensitive Secrets may be copied from restricted namespaces into a namespace controlled by the requester
- Credentials or other confidential data may be exposed to unauthorized users
- Exposed credentials could enable further access to applications or infrastructure
- Sensitive Secrets may be copied from restricted namespaces into a namespace controlled by the requester
- Credentials or other confidential data may be exposed to unauthorized users
- Exposed credentials could enable further access to applications or infrastructure
General mitigation guidance
Defensive approaches generally focus on separating trusted controller metadata from user-controlled input and enforcing authorization independently of labels.
- Verify the source and ownership of trigger resources rather than treating labels alone as proof of trust.
- Apply explicit authorization checks before generating or synchronizing sensitive resources.
- Restrict which users and workloads can create or update resources processed by generation handlers.
- Use least-privilege policies for service accounts and limit which namespaces and Secret types policies can access.
- Prefer secure-by-default policy designs that avoid copying secrets across trust boundaries unless explicitly authorized.
Defensive approaches generally focus on separating trusted controller metadata from user-controlled input and enforcing authorization independently of labels.
- Verify the source and ownership of trigger resources rather than treating labels alone as proof of trust.
- Apply explicit authorization checks before generating or synchronizing sensitive resources.
- Restrict which users and workloads can create or update resources processed by generation handlers.
- Use least-privilege policies for service accounts and limit which namespaces and Secret types policies can access.
- Prefer secure-by-default policy designs that avoid copying secrets across trust boundaries unless explicitly authorized.
How teams detect issues like this
- Review generation-handler code and policies for authorization decisions based solely on user-editable labels.
- Use static analysis and code review checks to identify trust decisions made from mutable metadata.
- Audit ConfigMap create and update events for Kyverno-related labels, especially when followed by Secret generation in another namespace.
- Enforce policy checks that restrict cross-namespace Secret generation and validate the identity and authorization of trigger resources.
- Review generation-handler code and policies for authorization decisions based solely on user-editable labels.
- Use static analysis and code review checks to identify trust decisions made from mutable metadata.
- Audit ConfigMap create and update events for Kyverno-related labels, especially when followed by Secret generation in another namespace.
- Enforce policy checks that restrict cross-namespace Secret generation and validate the identity and authorization of trigger resources.
