Hello Kubernetes Community,
in Go's net/http library causes invalid headers to be normalized and interpreted as valid by an HTTP server. If a reverse proxy in front of a Go HTTP server allows and forwards but doesn't normalize invalid headers, the Go server could interpret those headers differently than the reverse proxy.
If you are using an Authenticating Proxy
in front of your kube-apiserver, there are a set of headers that are used to pass user information from the proxy to the apiserver (suggested headers are "X-Remote-User", "X-Remote-Groups", "X-Remote-Extra-").
If your authenticating proxy accepts and forwards invalid headers, but expects to blacklist the known valid set of authenticating headers, it may be susceptible to a request with an invalid header that kube-apiserver would then treat as meaningful.
For example "X-Remote-User : cjcu...@google.com
" (with a space between the header key and the colon) could get past a blacklist that was specifically looking for "X-Remote-User:", but kube-apiserver would authenticate the request as coming from "cjcu...@google.com
". This could allow users that are able to authenticate to the front proxy the ability to impersonate other users or groups in the system.
The Kubernetes Release Team is in the process of building releases of 1.14, 1.15, & 1.16 to include the underlying Go net/http fix.
-CJ Cullen, on behalf of the Kubernetes Product Security Committee