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

https backend #1458

Closed
kfox1111 opened this issue Oct 2, 2017 · 14 comments
Closed

https backend #1458

kfox1111 opened this issue Oct 2, 2017 · 14 comments

Comments

@kfox1111
Copy link

kfox1111 commented Oct 2, 2017

I have a few services, (for example, DEX, kubernetes-dashboard) that do https termination themselves. Do to the sensitivity of the traffic they handle, I think it is good that they do so. I would still like to export their service out via an ingress though.

Can the ingress support passing a backend ca and letting the backend use https, reencrypting to the backend? If not, can this feature be added?

@kfox1111
Copy link
Author

kfox1111 commented Oct 2, 2017

Cool. I missed that. Thanks. :)

How do you specify the CA that the backend uses? I'm hoping the backends will use self signed certs and the frontend will use a wild card cert. This will add a layer of protection to our wildcard certs and reduce the cost of needing too many certs.

@aledbf
Copy link
Member

aledbf commented Oct 2, 2017

@kfox1111 you can use the directive server-snippet: "proxy_ssl_verify off;" in the configuration configmap or use a secret to mount the ca certificate.

@aledbf aledbf closed this as completed Oct 2, 2017
@kfox1111
Copy link
Author

kfox1111 commented Oct 2, 2017

turning off the validation negates some of the benefit of using ssl.

Mounting in the secret would help, but I'm looking for something like an ingress annotation that says what secret/configmap to pull out the ca.pem from for that backend. It would tell nginx-ingress what ca to use for that backend.

Is there a way to do that?

@aledbf
Copy link
Member

aledbf commented Oct 2, 2017

Is there a way to do that?

No. If you use SSL in your services you should consider to use a valid certificate

@aledbf
Copy link
Member

aledbf commented Oct 2, 2017

You can also build a custom image (just with FROM xxxx) and copy the ca cert to the ubuntu root certs directory

@kfox1111
Copy link
Author

kfox1111 commented Oct 2, 2017

Ok. Then I guess this is a feature request then. I see a case where the ingress provider (me) is separate from my users (namespaced), where they should manage their own ca, and through their particular ingress rules, specify what ca they signed their backends with. This means I don't need to give them my org's wildcard certs. When there are multiple distinct users (namespaces), there may be multiple ca's invovled and rebuilding an ingress to on board new users would be a heavy lift.

@kfox1111
Copy link
Author

kfox1111 commented Oct 2, 2017

looks like nginx supports it: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_certificate

So we'd need an annotation like: "ingress.kubernetes.io/secure-backend-ca" which would point to a configmap with a ca.pem in it. The ingress controller would download that configmap's ca.pem, place it somewhere nginx could get to, and override the proxy_ssl_certificate option on that ingress to point to the file.

What do you think?

@aledbf
Copy link
Member

aledbf commented Oct 2, 2017

Sure, PRs are welcome ;)

@kfox1111
Copy link
Author

kfox1111 commented Oct 2, 2017

ok. Can this issue please be reopened?

@aledbf
Copy link
Member

aledbf commented Oct 2, 2017

Please open a new issue with as feature request

@kfox1111
Copy link
Author

kfox1111 commented Oct 2, 2017

Ok. #1461

@jxadro
Copy link

jxadro commented Feb 25, 2019

Hi @aledbf it seems the PR #1461 is not progressing.

I'm also facing this requirement? It there anything we can do to make it progress, is it correctly tagged?

Thx.

@aledbf
Copy link
Member

aledbf commented Feb 25, 2019

@jxadro as I already said, someone needs to work on that

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

No branches or pull requests

3 participants