tnozicka / openshift-acme

ACME Controller for OpenShift and Kubernetes Cluster. (Supports e.g. Let's Encrypt)
Apache License 2.0
319 stars 116 forks source link

Add support for specifying a route label for validation routes in the context of router sharding #132

Closed Bengrunt closed 3 years ago

Bengrunt commented 4 years ago

What would you like to be added:

I would like to be able to set a route label to be used by validation routes in order for them to be exposed on a publicly accessible router.

Why is this needed:

In the context of router sharding I did not manage to make openshift-acme work.
I have multiple routers set up in my OKD 3.11 cluster. Some are accessible from the Internet, others are restricted to specific internal networks. I use route labels to select which route is exposed on which router, hence providing some kind of access control at the route level. My default router is not exposed to the internet, to prevent users from unknowingly exposing their deployments to the outside world.

Contrarily to what is stated in #69 the new ACME v2 implementation does not seem to make validation routes inherit their labels from the route labels. And anyway I'm not sure that's what I would like it to do, since my route might be exposed on a private router.

Ideally, I should be able to set a label for the validation route to be exposed on a public router while the route it validates is exposed on a private router.

Or maybe I missed something? Thanks a lot for your help !

@tnozicka

tnozicka commented 4 years ago

Contrarily to what is stated in #69 the new ACME v2 implementation does not seem to make validation routes inherit their labels from the route labels.

Can you make sure you're running the latest code? It should be there: https://github.com/tnozicka/openshift-acme/blob/63cf912/pkg/controller/route/route.go#L707

And anyway I'm not sure that's what I would like it to do, since my route might be exposed on a private router.

If your route is exposed on private router and not reachable from the internet, what good would signing a certificate for public hostname do for a route exposed only privately?

Ideally, I should be able to set a label for the validation route to be exposed on a public router while the route it validates is exposed on a private router.

Maybe I am not seeing the use case. Would you have a concrete example of what you are trying to achieve?

Bengrunt commented 4 years ago

Contrarily to what is stated in #69 the new ACME v2 implementation does not seem to make validation routes inherit their labels from the route labels.

Can you make sure you're running the latest code? It should be there: https://github.com/tnozicka/openshift-acme/blob/63cf912/pkg/controller/route/route.go#L707

I completely reinstalled openshift-acme from scratch so I guess so but I'll double check.

And anyway I'm not sure that's what I would like it to do, since my route might be exposed on a private router.

If your route is exposed on private router and not reachable from the internet, what good would signing a certificate for public hostname do for a route exposed only privately?

Ideally, I should be able to set a label for the validation route to be exposed on a public router while the route it validates is exposed on a private router.

Maybe I am not seeing the use case. Would you have a concrete example of what you are trying to achieve?

Sorry if I'm being unclear.

What I'd like to achieve is to be able to provide applications in a restricted context (company intranet, VPN accessible network, etc) with a valid letsencrypt certificate so that users don't need to accept security exceptions or get warnings in their browsers when accessing these applications.

For this, I could also used company generated or purchased certificates but:

Thanks for reaching back to me anyway :)

tnozicka commented 4 years ago

Hmm, I am not sure if you can split the same domain between different routers.

You'd have to have a public domain even for internal services and have DNS return different IP (the internal router) for request from local network to reach the internal router on the same public domain that is signed by let's encrypt.

Would using haproxy.router.openshift.io/ip_whitelist be easier?

Bengrunt commented 4 years ago

Yes that complicates things quite a bit. :)

I'm in the process of adding some kind of ACL at the cluster loadbalancer level (native Openshift HAProxy) to see if I can catch the HTTP-01 challenges (with the /.well-known/acme-challenge bit at this level and route them to the router exposing the challenge routes.

Otherwise a solution would be to resort to DNS-01 challenge but that's not supported yet by openshift-acme as I understood and I'm not even sure our internal DNS management service exposes a compatible API to process that kind of requests either...

Bengrunt commented 4 years ago

Would using haproxy.router.openshift.io/ip_whitelist be easier?

Did not manage to make this work :/

openshift-bot commented 4 years ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot commented 3 years ago

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

openshift-bot commented 3 years ago

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift-ci-robot commented 3 years ago

@openshift-bot: Closing this issue.

In response to [this](https://github.com/tnozicka/openshift-acme/issues/132#issuecomment-744077825): >Rotten issues close after 30d of inactivity. > >Reopen the issue by commenting `/reopen`. >Mark the issue as fresh by commenting `/remove-lifecycle rotten`. >Exclude this issue from closing again by commenting `/lifecycle frozen`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.