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.<p>[0] <a href="https://github.com/jetstack/kube-lego" rel="nofollow">https://github.com/jetstack/kube-lego</a>
This is cool. I also wrote a Marathon/Mesos version, without the vendor lock-in: <a href="https://mesosphere.com/blog/2016/04/06/lets-encrypt-dcos/" rel="nofollow">https://mesosphere.com/blog/2016/04/06/lets-encrypt-dcos/</a>
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.<p>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.<p>See the proposed exec based plugin model: <a href="https://github.com/kelseyhightower/dns01-exec-plugins" rel="nofollow">https://github.com/kelseyhightower/dns01-exec-plugins</a>
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.<p>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.