Repository navigation
kubernetes chart: a client-supplied X-Remote-Uid reaches tenant extension servers while a v1.31 to v1.32 control-plane upgrade rolls #4371
Description
Activity
One open point from the description is settled. I wrote that I had not checked what a v1.31 trust controller does to the key once a v1.32 replica has published it. Two independent reads of the controller at v1.31 and v1.32 agree: the v1.31 replica rebuilds
extension-apiserver-authenticationwithoutrequestheader-uid-headers, so during the roll the key comes and goes as replicas of both versions rewrite the ConfigMap. The window flickers rather than holds, and a single look at the ConfigMap during the roll proves nothing either way. The docs sentence for this is in the follow-up PR.Obsolete with #4407. The window needs a v1.31 aggregator and a replica that publishes
requestheader-uid-headersserving at the same time. After #4407 the chart renders the UID flags only from v1.33, and a control plane cannot roll from v1.31 to v1.33 in one step. On a v1.32 to v1.33 roll the older aggregator already strips a client-suppliedX-Remote-Uid. No release shipped the v1.32 path.
During a control-plane version bump from v1.31 to v1.32 on a tenant with
spec.oidc.modeother thanNone, the two apiserver versions serve side by side while the Deployment rolls (controlPlane.replicasdefaults to 2), and for that window an aggregated API server inside the tenant can be handed a UID the client chose.Mechanism, read at the pinned client-go. A v1.31 aggregator strips
X-Remote-User,X-Remote-GroupandX-Remote-Extra-*from the incoming request before proxying and does not knowX-Remote-Uid, so a client-supplied one passes through (transport/round_trippers.go,SetAuthProxyHeadersat v0.31.14). From v1.32 the same function deletesX-Remote-Uidas well (v0.32.13). Once the first v1.32 replica is up it publishesrequestheader-uid-headersintoextension-apiserver-authentication, which is what #3539 renders, so an extension server built onk8s.io/apiserverstarts trusting that header. A request that lands on a v1.31 replica during the roll therefore reaches the extension server with whateverX-Remote-Uidthe client sent.Severity is low. The username and groups still come from the v1.31 aggregator's own authentication and cannot be spoofed this way, RBAC does not consult the UID, and the window closes when the last v1.31 replica is gone. I have not checked whether a v1.31 trust controller drops the key again when it rewrites the ConfigMap; if it does, the window flickers instead of holding.
Two possible homes: a sentence in
docs/oidc-tenant.mdtelling operators that UID-based decisions in tenant extension servers are unreliable until a version bump from v1.31 has finished, or nothing, on the grounds that this is upstream version-skew behaviour. Found during review of #3539 and not changed there.