Summary
The kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own X-Remote-Group and X-Remote-Extra-* headers, which the shard trusts as a verified identity assertion — allowing a low-privilege user to escalate to cluster administrator (system:masters) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass.
Imapct
In a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (X-Remote-User / X-Remote-Group / X-Remote-Extra-*). The shard trusts these headers because they arrive over the front-proxy's mutually-authenticated connection.
Because the front-proxy appended its identity headers instead of replacing them — and never removed any copies the client sent — an authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could:
- assert
X-Remote-Group: system:masters and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard;
- forge
authorization.kcp.io/warrant to assume an arbitrary user/group identity via kcp's delegated-identity mechanism;
- forge
authentication.kcp.io/scopes to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace;
- satisfy per-workspace required-group gating by injecting the required group.
The result is arbitrary read/write/delete access to any tenant's resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters — a cross-workspace access break and authorizer bypass across the proxy's trust boundary.
Patches
Fixed in v0.31.4, 0.32.2 The front-proxy and the shard's in-process local-proxy now unconditionally remove any inbound X-Remote-* identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard.
Operators should upgrade to a patched release. No configuration changes are required after upgrading.
Workarounds
There is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping X-Remote-User, X-Remote-Group, and all X-Remote-Extra-* headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim.
Credit to 5ud0er / Tarmo Technologies.
Summary
The kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own
X-Remote-GroupandX-Remote-Extra-*headers, which the shard trusts as a verified identity assertion — allowing a low-privilege user to escalate to cluster administrator (system:masters) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass.Imapct
In a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (
X-Remote-User/X-Remote-Group/X-Remote-Extra-*). The shard trusts these headers because they arrive over the front-proxy's mutually-authenticated connection.Because the front-proxy appended its identity headers instead of replacing them — and never removed any copies the client sent — an authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could:
X-Remote-Group: system:mastersand act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard;authorization.kcp.io/warrantto assume an arbitrary user/group identity via kcp's delegated-identity mechanism;authentication.kcp.io/scopesto escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace;The result is arbitrary read/write/delete access to any tenant's resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters — a cross-workspace access break and authorizer bypass across the proxy's trust boundary.
Patches
Fixed in v0.31.4, 0.32.2 The front-proxy and the shard's in-process local-proxy now unconditionally remove any inbound
X-Remote-*identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard.Operators should upgrade to a patched release. No configuration changes are required after upgrading.
Workarounds
There is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping
X-Remote-User,X-Remote-Group, and allX-Remote-Extra-*headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim.Credit to 5ud0er / Tarmo Technologies.