I've been using kube-lego [0] to request/renew certs from LE. It doesn't handle the DNS for you automatically, which has the benefit of working outside of GKE and downside of having to configure DNS yourself. It's been working well.

[0] https://github.com/jetstack/kube-lego

I'm using this for rolling out test environments and so far it works amazingly well. Wildcard DNS record to an ELB, and with just the one kube-lego pod + the one single ingress annotation i automatically get new environments provisioned in under 10 minutes including app bootstrap. As a recovering sysadmin (some fools now call me devops;) this is stuff i thought of being the holy grail 5 years ago.

Can you explain this a little more? I am going to try this out this weekend. It does sound like the holy grail!

I think kube-cert-manager is a bit more flexible. I'm using kube-lego now but I'd like to switch to kube-cert-manager. kube-lego seems fairly integrated with Ingress, since it needs to be able to write custom route handlers for the HTTP challenge. Since my cloudprovider doesn't have an Ingress Controller yet, I'd prefer to use plain LoadBalancer services instead of Ingress.

Interestingly, kube-lego requires DNS to be configured correctly anyway so that lego can verify the http challenge (implicitly requiring the DNS A record). kube-cert-manager though, could retrieve the cert automatically before the A record is ever created and propagated.

Theoretically, you could make this work with any DNS provider with an API. Much the same way that lego does: https://github.com/xenolf/lego/tree/master/providers/dns

AFIACT you still have to configure the DNS A record yourself, kube-cert-manager just solves the challenges using DNS.

This is cool. I also wrote a Marathon/Mesos version, without the vendor lock-in: https://mesosphere.com/blog/2016/04/06/lets-encrypt-dcos/

I'm proposing an exec based plugin system for the Kubernetes Certificate Manager. Ideally this will make it easy to support any DNS provider written in any language.

The goal is to push all DNS providers, including the Google DNS provider, to exec plugins that live out of tree. To ease deployments the "official" Kubernetes Certificate Manager container will include a few DNS providers via exec plugins out of the box. There will be instructions on how to build new containers with additional providers for custom deployments. More details soon.

See the proposed exec based plugin model: https://github.com/kelseyhightower/dns01-exec-plugins

I've updated the Kubernetes Certificate Manager based on the dns01 exec plugins proposal. I've also pulled out all native support for DNS providers and now the Google DNS provider requires the googledns exec plugin. For ease of use the kube-cert-manager container image includes the googledns plugin, but it's easy to now build and ship your own:

https://github.com/kelseyhightower/kube-cert-manager/blob/ma...

What needs to be done for this to not have the Google requirements?

User feedback and clear demand for other DNS providers. Once I have that I'll consider refactoring the DNS backend to support anything with an API or some sort of plugin system.

Current goals are to vet the idea of using DNS-01 challenges and get the UX right.

Have you looked into https://github.com/xenolf/lego ? This project already have support for many DNS providers.

The logic that lego has could certainly be coopted here but having a declarative config for the certificate using ThirdPartyResource is the right way to go IMHO.

Also, lego is a bit cumbersome to run in a container. It relies on storing config and certs in a .lego dir in the home directory, and doesn't clean up DNS entries if it somehow fails to run so it would be a pain to use without modification.

I'd really like to add support for Azure and Cloudflare (I'm very familiar with the Go SDK for Azure and have written a dynamic dns client for Cloudflare previously).

I think they should be possible to support with no or minimal changes to the API you have in the GCE provider currently. Mostly just need to make changes around the service-account/secret handling, I believe.

Based on user feedback, this is going to happen. I'll need a few days to clean up and refactor things, but it should be pretty easy to add support for any DNS provider with an API.

Heh, when I wrote this comment I hadn't yet realized you force pushed over the original repo layout :)

This requires a registered DNS domain managed by Google Cloud DNS -- I wonder how much work it would take to make that also work with AWS Route53?

I was wondering when someone would try that. I built a k8s cluster from the CoreOS tutorials. Generating certs had contributed to the friction.

Very cool. Just started looking for a solution here, and wasn't sold on the Ingress-based approach of kube-lego; I want to be able to do HTTPS-to-the-Pod, so terminating on the Ingress is a no-go for my use-case.

Also great work Kelsey on providing a solid example of how to structure a complex k8s integration.

I actually clicked the link hoping to see a good example of how to extend Kubernetes and I was not disappointed. I'm thinking of writing a plugin that registers DNS names based on a custom annotation on a Service resource.