Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip validation of upstream certificate #75

Closed
lentzi90 opened this issue Feb 25, 2019 · 5 comments · Fixed by #234
Closed

Skip validation of upstream certificate #75

lentzi90 opened this issue Feb 25, 2019 · 5 comments · Fixed by #234

Comments

@lentzi90
Copy link
Contributor

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
Copy link
Contributor

ploxiln commented Feb 25, 2019

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
Copy link
Contributor

ploxiln commented Feb 25, 2019

(By the way, in my own fork, I did the insecure transport a bit differently: ploxiln/oauth2_proxy@84305f7)

@JoelSpeed
Copy link
Member

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
Copy link

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

@kfox1111
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants