Kubectl proxy Strips out Authorization header

[crestenstclair]

Bug Report
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.6", GitCommit:"e569a27d02001e343cb68086bc06d47804f62af6", GitTreeState:"clean", BuildDate:"2016-11-12T05:22:15Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.6", GitCommit:"e569a27d02001e343cb68086bc06d47804f62af6", GitTreeState:"clean", BuildDate:"2016-11-12T05:16:27Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

• Cloud provider or hardware configuration: GKE
• OS (e.g. from /etc/os-release): OSX
• Kernel (e.g. uname -a): Darwin15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36
• Install tools:
• Others:

What happened:

1. I call kubectl proxy, and connect to my cluster.

2. Then I attempt to communicate with my app via proxy, by using postman to send requests to: http://localhost:8001/api/v1/proxy/namespaces/default/services/apiserver:80

3. My API always returns 401, due to the fact that my Authorization header has been stripped out of the request.

What you expected to happen:
To successfully communicate with my apiserver, with my Authentication header in tact

How to reproduce it (as minimally and precisely as possible):

1. kc proxy
2. use postman to make a request against a service, with authorization header containing random value
3. observe that the Authorization header has been removed

[mrook]

This bit me as well. After some debugging it looks like the Authorization header is actually sent (in src/net/http/request.go), but stripped somewhere down the line (kube-proxy perhaps?).

[crestenstclair]

This PR looks relevant: #34076

[lattwood]

I was bit by the opposite behaviour, when trying to utilize grafana. Connecting via the apiserver's proxy, the Authorization header is passed to Grafana. Grafana didn't recognize the token in the header, and returned a 403/401.

When I was writing up the bug, I realized it was a security issue- the Authorization header was being disclosed to whatever is behind the proxy, and it occurs silently and without the user's approval.

[crestenstclair]

What I ended up doing is writing an haproxy script to set incoming Authorization -> Local-Authorization. Then, I set up a service that I have my developers talk to that sets Local-Authorization -> Authorization

Ended up working pretty well, and is trivial to do in haproxy.

[liggitt]

this is working as expected. "proxying" through the apiserver will not get you standard proxy behavior (preserving Authorization headers end-to-end), because the API is not being used as a standard proxy

a regular proxy would:

• return Proxy-Authenticate headers, and honor/strip-out Proxy-Authorization headers
• pass-through WWW-Authenticate and Authorization headers
• expect the desired destination host as a Host header
• expect the desired destination path as the full request path

the api server:

• does not distinguish proxy subresource URLs from the rest of the API
• authenticates the entire API uniformly
• expects the desired destination host to be deriveable from the named pod or service
• expects the desired destination path as a subpath of the proxy subresource API path

additionally, propagating the Authorization header sent to the API on to the backend pods is potentially dangerous, since clients would not expect pods to see their API credentials.

[therealplato]

I got around this by routing through an ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: bla
  namespace: bla
  annotations:
    ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx-internal"
    ingress.kubernetes.io/ssl-redirect: "true"
spec:
  rules:
  - host: bla.bla.bla 
    http:
      paths:
      - path: /bla/bla
        backend:
          serviceName: bla
          servicePort: 80