openshift-acme
openshift-acme copied to clipboard
tnozicka
Support DNS validation method
Hi,
I have an openshift deployment where the routes are not internet accessible, so I need to use dns to do domain verification instead.
Does openshift-acme support the dns method? I saw some passing references, but I have no idea how to actually configure it.
I'd be using Route 53 in the first case.
Thanks
Hi,
I'm also interested in dns challenge. Just like @pearj I have an openshift cluster where routes are not accessible from the internet. Instead of Route 53 I'm using google cloud dns.
I saw that you have to develop a plugin. Is there any further information? I would like to develop one for the google cloud platform, if there isn't already one.
Thanks
Hi @pearj and @andreas-kowasch
unfortunately openshift-acme doesn't support dns challenges yet. But let me assure you that I see this as a perfectly valid use case and this is on our roadmap.
As the DNS exposing is heavily dependent on your provider API the plan is to use plugin API to support wide range of provides.
I don't suppose we can leverage the existing certbot plugins somehow?
Maybe you could use https://github.com/go-python/gopy or https://github.com/sbinet/go-python then you could re-use all of the existing plugins in go?
What do you think?
For the long term I'd like to do the DNS plugin REST based to be language independent so you would just wrap those in simple http server.
To start with I'll probably use some of the native Go ones already there.
Let's Encrypt recently started offering wildcard certs, with DNS validation only. Is this interesting for openshift-acme?
- Could potentially maintain a wildcard router default cert (also stored in a secret,
router-certsindefaultnamespace). Not sure it has benefit if you're running openshift-acme for individual routes anyway? Though it does allow routes on the default subdomain to be instantaneously valid instead of waiting for LE. - The main use case IMHO is an openshift so firewalled/isolated that letting it control public DNS is impractical; in such an env, a wildcard cert is the next best thing, it's not too hard to "smuggle" one from outside every 3 month. This use case sounds like it belongs better in openshift-ansible (or a small standalone playbook); again, one needs to plug the part to control your DNS but ansible has tons of modules for these.
Yes, wildcard certs are interesting mainly because of providing them for default router and thus for routes using the default domain. In some environments users are not allowed to have custom host or upload their own certs.
I guess that raises priority for implementing DNS challenge. When the rewrite merges, things should get moving more fluently.
Now that the rewrite has been merged and seems to have improved the overall state very well, are there any plans to continue on this side of things? DNS validation would be a great addition, as Wildcard support get's requested more and more.
About plugins: there is discussion on https://github.com/kubernetes-incubator/external-dns/issues/555 about what it would take for external-dns to abstract this away.
That looks promising at least as a library. Thanks for pointing that out. Every time CRD is involved people don't think about multitenancy and we can't use that directly though.
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
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
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-bot: Closing this issue.
In response to this:
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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@tnozicka: Reopened this issue.
In response to this:
/reopen /remove-lifecycle rotten /lifecycle frozen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
