Oauth2-proxy: Skip validation of upstream certificate

[lentzi90]

Even with -ssl-insecure-skip-verify it is not possible to use a self-signed certificate for the upstream.

Expected Behavior

Upstream with self-signed certificate (such as default kubernetes dashboard deployment) should work if oauth2-proxy is configured with -ssl-insecure-skip-verify.

Current Behavior

Oauth2-proxy still tries to verify the certificate and fails with the following error message:

reverseproxy.go:395: http: proxy error: x509: certificate has expired or is not yet valid

Possible Solution

This issue was reported here in the bitly/oauth2_proxy repository and has a pull request with a proposed solution here.

Steps to Reproduce (for bugs)

I have followed this guide but modified it a bit.

1. Install minikube, kubectl and helm
2. Clone this repo
3. Checkout the branch self-signed-dashboard
4. Follow the quick start
5. Check the logs of the oauth2-proxy pod

Context

The default dashboard deployment uses self-signed certificates and this is better than no TLS at all.
I think this is a common use case, especially in a kubernetes environment.

Your Environment

Versions used:

• Kubernetes v1.13.3
• Minikube v0.34.1
• Oauth2-proxy chart 0.9.1
• Oauth2-proxy 3.1.0

[ploxiln]

You don't really want to use this to connect to an upstream with a self-signed cert in a normal/production situation, because it applies to requests to the provider (google, github, etc) as well. So it would be better to use plain http to connect to the upstream, which should be fine if it is on the same network segment (VPC, lan, cluster, etc), so that requests to the remote provider are secure.

[ploxiln]

(By the way, in my own fork, I did the insecure transport a bit differently: https://github.com/ploxiln/oauth2_proxy/commit/84305f7485bf53b2125a8e97a3246fdf1f9878eb)

[JoelSpeed]

because it applies to requests to the provider

Perhaps a separate insecure upstream flag is required so that the two can be separated, this is kind of what I would expect of a proxy like this

[michaelajr]

Hit this issue today as I was setting up a proxy for the Dashboard.

[kfox1111]

I struggled getting this working over the weekend too. I ended up with launching the kube-dashboard and oauth2_proxy charts, with this annotation for the dashboard:

  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-response-headers: Authorization
    nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=$request_uri
    nginx.ingress.kubernetes.io/auth-url: https://$host/oauth2/auth
    nginx.ingress.kubernetes.io/configuration-snippet: |
      auth_request_set $name_upstream_1 $upstream_cookie_name_1;
      access_by_lua_block {
        if ngx.var.name_upstream_1 ~= "" then
          ngx.header["Set-Cookie"] = "name_1=" .. ngx.var.name_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
        end
      }
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/secure-backends: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

Some of the annotation only works on nginx-ingress 0.22 but not 0.20. fyi.

and for oauth2_proxy:

 configFile: |-
    pass_authorization_header = true
    set_authorization_header = true
    ssl_insecure_skip_verify = true

I'm sure some of the things are not required so might be able to simplify it a bit. I got stuck for many hours and the set_authorization_header=true was the thing that really unwedged things.

I've got some other notes. maybe I can distil it down further. Should we try and document how to deploy a working keycloak/oauth2_proxy/kube-dashboard/kube-apiserver/minikube setup?