PalmStoneGames / kube-cert-manager

Manage Lets Encrypt certificates for a Kubernetes cluster.
Apache License 2.0
540 stars 102 forks source link

Support openshift's routes #20

Open ibotty opened 7 years ago

ibotty commented 7 years ago

It would be great to optionally support openshift's routes. They are similar to ingresses, but not (yet) compatible.

luna-duclos commented 7 years ago

Is there a spec and/or documentation about them available somewhere ?

ibotty commented 7 years ago

Sorry, I missed your question.

There is. https://docs.openshift.org/latest/dev_guide/routes.html

The main complication will be cross-namespace support for the http challenge. That will need a proxy pod in the routes namespace. Other than that, it is only about modifying a kube object. I can provide some shell snippets that do that if you find that useful.

luna-duclos commented 7 years ago

afaik cross-namespace support for http already works for ingress/cert objects, so I don't expect that'd be much of an issue ? Just need to proxy the correct path to kcm

ibotty commented 7 years ago

In openshift, routes for the same hostname can only exist in the same namespace. Routes can only point to services in the same namespace. That's a limitation of openshift's routes, not of cert-manager.

It might be possible to have a service with explicit endpoint (the certmanager's service IP) though. I'll check that next week.

ssendev commented 7 years ago

It's possible to have cross namespace services: https://docs.openshift.com/container-platform/3.4/dev_guide/integrating_external_services.html

ibotty commented 7 years ago

That only works when the namespaces can communicate with each other. But yes, It's a possibility.

ssendev commented 7 years ago

https://docs.openshift.org/latest/architecture/additional_concepts/sdn.html#architecture-additional-concepts-sdn suggests that at least with the ovs-multitenant plug-in it's possible to assign a project VNID 0, which causes it to be accessible from every project.

ssendev commented 7 years ago

Ok I did some tests with ovs-multitenant. VNID 0 works as expected, but what's interesting is that it's not even needed. Just having the service and endpoint works too. At least from external sources which is all we care about.

So lets say we have a ns LE and a ns A with a service and endpoint which point to a service in LE. When they are on different VNIDs pods in A can't access stuff in LE but when an external request comes to A and the route points to the service which points to LE it works. I believe it's like that because external traffic flows through VNID 0 https://docs.openshift.com/container-platform/3.4/architecture/additional_concepts/sdn.html#sdn-packet-flow

paralin commented 7 years ago

I'm interested in completing this, is there any info on what needs to be done?

luna-duclos commented 7 years ago

I know nothing about openshift, is there anyone that does ?

ibotty commented 7 years ago

No released openshift supports thirdpartyresources yet, so it is hard to test.

paralin commented 7 years ago

I can add a service with external endpoints just fine. But that shouldn't even be necessary.

With openshift router it should be super easy. Just create a certbot service and pod in the target namespace and direct the routing of the to-be-ssl route to the certbot container temporarily until the verification is complete.

Under kubernetes you could do similar with ingress controllers. Also, I would propose writing a second approach that uses the cloudflare API for example to complete the DNS verification of let's encrypt to avoid even dealing with this crap at all.