DNS Challenge Support about kube-lego HOT 19 CLOSED

i thought i should drop https://github.com/xenolf/lego in here as it is a go implementation which supports the dns challenge.

from kube-lego.

@simonswine I'm building a POC to write the dns challenge. The ideia is to parse the ingress annotations and create the dns challenge (supporting multiple providers).

I'll submit the PR during this weekend, so we can discuss about it.

from kube-lego.

Hi,

I'm running Kube-Lego behind a Google firewall that for security purposes, locks down access to a handful of controlled IPs.

Right now, I need to open up the firewall every time I need to renew the cert, then close it back down, which is a PITA (especially given that I don't actually know when Lego will attempt a renewal), though no impossible. However, I would be a lot happier if I could practically forget about Lego running on my cluster and just use the DNS challenge for verification.

from kube-lego.

I still don't think it's a good idea that kube-lego talks to DNS providers. I'd like to keep it simple. Do one thing and do it well.

@SchwarzM I am no longer using the lego library, as it's not really easy to get a good feedback for failing authorisations. I am now on https://godoc.org/golang.org/x/crypto/acme

I also acknowledge your private networking/offline/China use cases. My idea would involve a manual DNS challenge. I could see kube-lego writing the challenge response (that needs be setup as a DNS record into an secret file). From there on it could be processed further into DNS by a another tool or just manually configured. (Something like https://github.com/wearemolecule/route53-kubernetes)

from kube-lego.

Awesome, thanks! I should have noted that I added my comment less as a request for action and more as Google bait because this issue ranks pretty high on appropriate Google searches. But now I have two options when I thought I had zero: the certificate copy method or transitioning to cert-manager. Which solution I choose will probably depend on how soon I have to transition another site again.

from kube-lego.

Sorry this is not really a priority for me know. (Would involve a lot of DNS backends). The current challenge is planned, but I haven't seen it implemented in a Let's Encrypt client API

from kube-lego.

This is something that should really be a higher priority. Lego itself already has inherent support for a ton of backends so I can't see it being that hard. There is a huge usecase here whereas people won't have to create records that point to their LB if they don't want to. Additionally, internal LB instances (ClusterIP) serving internal cluster applications will be able to obtain valid certs for those services without any problem.

Myself (and company) are somewhat interested in this as kube-lego seems to be the leader in certificate handling for k8s clusters ;)

from kube-lego.

One more use case: china servers. There are no access to 80/443 ports without ICP license.

from kube-lego.

Guys I builded a POC for dns challenge support. I tried to abstract the dns layer to keep easy to add support for other dns providers.

For now just route53 is supported, I haven't finished all (some methods are not yet implemented) so I'm open for changes.

from kube-lego.

traefik supports dns challenge, maybe you can copy the code

from kube-lego.

How about a pluggable dns challenge impl similar to kube-cert-manager's?

Sounds like supporting DNS challenge is important for all kinds of reasons. I'll add one more: if you enable Google's Identity-Aware Proxy on the GCE Load Balancer that kube-lego uses, LE can no longer complete the http challenge.

from kube-lego.

@simonswine What if just a DNS-01 challenge interface were added, and leave it up to the community to write and contribute the various DNS backends as independent modules? Since golang doesn't support loadable libs/modules, then for those that need DNS-01 challenge support can flip a few switches during build time to pull in the required DNS backend module.

@devth Thanks for the mention of: https://github.com/PalmStoneGames/kube-cert-manager
Initial lookover, it may accomplish what we need as HTTP challenges + firewall == PITA due to LE not wanting to release any validator whitelists.

@zmeggyesi We are in the same boat.

from kube-lego.

from kube-lego.

We were also stuck not being able to use kube-lego since our servers are behind CloudFlare, which is preventing the HTTP challenge from succeeding as long as the server is being proxied.

I came across kube-cert-manager - there are actually 2 forks, but https://github.com/PalmStoneGames/kube-cert-manager is the fork with support for ACME HTTP-01, SNI-TLS-01 or DNS-01 challenge, using https://github.com/xenolf/lego as the ACME client.

After updating the kube-cert-manager deployment for my DNS provider (cloudflare) and deploying it, it works pretty much just like kube-lego when using ingresses.

In the ingress definition, just change:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.class: "nginx"

to

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  labels:
    stable.k8s.psg.io/kcm.class: "default"
  annotations:
    kubernetes.io/ingress.class: "nginx"

And voila, it behaves exactly like kube-lego except for supporting DNS challenges.

It looks like kube-cert-manager is interested in moving to kubernetes incubator (PalmStoneGames/kube-cert-manager#33).

from kube-lego.

kube-cert-manager won't keeep let's encrypt certificates in secrets but requires persistent disk

from kube-lego.

I don't think kube-lego will ever support DNS challenges for ACME. We've instead re-focused our efforts on cert-manager instead, which is backed by custom resources and is where I've been spending the majority of development time.

The plan is to gradually deprecate kube-lego in favour of cert-manager, as we get more user feedback on the new project and it's stability.

from kube-lego.

Another use case for DNS validation: seamless transition. If example.com is on a legacy server with a valid certificate, then moving it onto a cluster with kube-lego has a chicken and egg problem: when do you move the DNS entry? If you move it before you add the ingress entry, then it'll 404 for the DNS propogation time period, and then for a couple of minutes while kube-lego does it's stuff. If you move it after the ingress entry is created, then kube-lego will have failed to get a certificate, and may even have triggered the Let's Encrypt rate limiter, which means you're down for > 1 hour. If we had DNS validation, both the new and the old clusters could get valid certificates no matter when the DNS entry is switched over.

from kube-lego.

As I've said before, kube-lego will not be implementing support for DNS01 validation.

cert-manager is where efforts are being focused, and it currently supports both DNS01 validation and HTTP01 validation (with support for all ingress controllers that I am aware of).

@joe1chen to answer your comment about re-inventing the wheel, we did host a call with the kube-cert-manager team regarding the new project, and it was agreed a new project was best in order to not constrain the design of the project. It is now also possible to transition from a kube-lego setup to cert-manager fairly easily (although documentation is still to be written on the best way to do this - cert-manager/cert-manager#136).

@bryanlarsen whilst we won't be adding DNS01 validation, despite your (very valid) use case. This is still possible with HTTP01 by simply copying your existing certificate into your Kubernetes cluster. kube-lego (or cert-manager) will then 'adopt' this certificate and auto renew it when appropriate.

I am going to close this issue now, as it's not something we intend to support as part of kube-lego. Please take a look at our user guides in cert-manager for more information on how you can get up and running, and feedback is highly welcomed! https://github.com/jetstack/cert-manager/tree/master/docs/user-guides

from kube-lego.

Thanks for documenting your use case all the same! Definitely helps people find the information they need!

from kube-lego.