Summary
Traefik's Kubernetes Ingress provider may accept annotation references to routing and transport objects located in another namespace without validating namespace boundaries. An attacker who can create or update an Ingress or Service resource may use this behavior to access tenant-injected credentials, reuse client certificates, or bypass intended tenant isolation.
Traefik's Kubernetes Ingress provider may accept annotation references to routing and transport objects located in another namespace without validating namespace boundaries. An attacker who can create or update an Ingress or Service resource may use this behavior to access tenant-injected credentials, reuse client certificates, or bypass intended tenant isolation.
Affected context
The issue occurs in Traefik deployments using the Kubernetes Ingress provider when annotation-based references to Middlewares, ServersTransports, or TLSOptions are resolved without enforcing that referenced objects belong to the same authorized namespace. It is most relevant in multi-tenant clusters where tenants can create or modify Ingress or Service resources while namespace boundaries are expected to limit access to routing and transport configuration.
The issue occurs in Traefik deployments using the Kubernetes Ingress provider when annotation-based references to Middlewares, ServersTransports, or TLSOptions are resolved without enforcing that referenced objects belong to the same authorized namespace. It is most relevant in multi-tenant clusters where tenants can create or modify Ingress or Service resources while namespace boundaries are expected to limit access to routing and transport configuration.
Exploit preconditions
- Attack surface: Kubernetes Ingress and Service annotations processed by Traefik
- Required access: Permission to create or update an Ingress or Service resource in at least one namespace
- Trigger point: Traefik configuration reconciliation after the resource is created or modified
- Why exploitation is possible: Annotation references can resolve to selected objects in other namespaces without adequate namespace authorization checks
- Relevant objects: Middlewares, ServersTransports, and TLSOptions containing tenant-specific credentials or client-certificate settings
- Attack surface: Kubernetes Ingress and Service annotations processed by Traefik
- Required access: Permission to create or update an Ingress or Service resource in at least one namespace
- Trigger point: Traefik configuration reconciliation after the resource is created or modified
- Why exploitation is possible: Annotation references can resolve to selected objects in other namespaces without adequate namespace authorization checks
- Relevant objects: Middlewares, ServersTransports, and TLSOptions containing tenant-specific credentials or client-certificate settings
Why this happens
The underlying bug is an authorization failure caused by treating user-controlled resource references as valid without verifying their namespace scope. This maps to CWE-862: Missing Authorization, because the provider does not consistently enforce the access boundary required before using configuration objects from another tenant's namespace. The insecure pattern is cross-namespace reference resolution based on annotation values without an explicit allowlist, ownership check, or equivalent policy decision.
The underlying bug is an authorization failure caused by treating user-controlled resource references as valid without verifying their namespace scope. This maps to CWE-862: Missing Authorization, because the provider does not consistently enforce the access boundary required before using configuration objects from another tenant's namespace. The insecure pattern is cross-namespace reference resolution based on annotation values without an explicit allowlist, ownership check, or equivalent policy decision.
Potential impact
- An attacker could reuse another tenant's injected credentials
- An attacker could cause requests to use another tenant's client certificates
- Tenant isolation could be bypassed
- Requests could be routed through unauthorized middleware or transport settings
- Confidentiality and integrity of tenant traffic could be affected
- The affected cluster's trust boundaries could be weakened
- An attacker could reuse another tenant's injected credentials
- An attacker could cause requests to use another tenant's client certificates
- Tenant isolation could be bypassed
- Requests could be routed through unauthorized middleware or transport settings
- Confidentiality and integrity of tenant traffic could be affected
- The affected cluster's trust boundaries could be weakened
General mitigation guidance
Mitigation generally focuses on enforcing namespace-aware authorization for every annotation-derived reference.
Common defensive patterns include:
- Resolving referenced objects only within the originating namespace by default
- Requiring explicit, centrally controlled policy for approved cross-namespace references
- Applying strict allowlists to referenceable object kinds and namespaces
- Limiting tenant permissions to the Ingress and Service resources they are authorized to manage
- Avoiding storage of reusable credentials or client certificates in broadly referenceable configuration objects
- Running Traefik with the minimum Kubernetes permissions required for its provider operations
- Monitoring and reviewing cross-namespace reference behavior as part of multi-tenant policy enforcement
Mitigation generally focuses on enforcing namespace-aware authorization for every annotation-derived reference.
Common defensive patterns include:
- Resolving referenced objects only within the originating namespace by default
- Requiring explicit, centrally controlled policy for approved cross-namespace references
- Applying strict allowlists to referenceable object kinds and namespaces
- Limiting tenant permissions to the Ingress and Service resources they are authorized to manage
- Avoiding storage of reusable credentials or client certificates in broadly referenceable configuration objects
- Running Traefik with the minimum Kubernetes permissions required for its provider operations
- Monitoring and reviewing cross-namespace reference behavior as part of multi-tenant policy enforcement
How teams detect issues like this
Detection can combine configuration review, authorization testing, and runtime monitoring:
- Use static analysis or policy checks to flag annotation values that reference resources outside the owning namespace
- Review provider code and configuration for cross-namespace lookups lacking explicit authorization checks
- Test whether tenant-created Ingress and Service resources can select Middleware, ServersTransport, or TLSOption objects from other namespaces
- Audit Kubernetes RBAC rules for tenants that can modify routing resources
- Monitor Traefik configuration events and logs for unexpected cross-namespace references
- Enforce admission policies that reject unauthorized reference patterns before resources reach the provider
Automated code and manifest review tools may help identify missing namespace-boundary checks during development and deployment.
Detection can combine configuration review, authorization testing, and runtime monitoring:
- Use static analysis or policy checks to flag annotation values that reference resources outside the owning namespace
- Review provider code and configuration for cross-namespace lookups lacking explicit authorization checks
- Test whether tenant-created Ingress and Service resources can select Middleware, ServersTransport, or TLSOption objects from other namespaces
- Audit Kubernetes RBAC rules for tenants that can modify routing resources
- Monitor Traefik configuration events and logs for unexpected cross-namespace references
- Enforce admission policies that reject unauthorized reference patterns before resources reach the provider
Automated code and manifest review tools may help identify missing namespace-boundary checks during development and deployment.
