Support openshift's routes

[ibotty]

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

[luna-duclos]

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

[ibotty]

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]

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]

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]

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

[ibotty]

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

[ssendev]

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]

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]

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

[luna-duclos]

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

[ibotty]

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

[paralin]

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.