Skip validation of upstream certificate about oauth2-proxy

[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?

[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: ploxiln/oauth2_proxy@84305f7)