digitalocean-cloud-controller-manager

digitalocean-cloud-controller-manager copied to clipboard

Need to pull in the latest version of godo that includes https://github.com/digitalocean/godo/pull/165.

Get DNS names from annotations?

cc @cagedmantis

godo updated in #93.

I don't believe digitalocean-cloud-controller-manager currently supports Certificates (IIRC, you can only uses existing one with ID). So, we'll need to add annotations for Certificate payload (private key, certificate chain, leaf certificate) and type (custom or lets_encrypt).

DNS names maybe could be obtained from API, not sure are there annotations by default.

That is true, the current implementation of LBs require that the certificate was already created and that you know the certificate ID. The new Let's Encrypt feature means that we don't have to have the certificate created, we just need a DigitalOcean domain that we can use.

One thing to note is that the Let's Encrypt feature currently does not support wildcard domains, meaning that though users don't need to manually create certificates, they still need to manually create a domain at least once. From there we may want to programmatically create subdomains so users don't have to create them for every LB.

Does DigitalOcean Kubernetes have the ability to use lets encrypt to use a domain name with https? There are docs online but not sure if there is an update or examples on how to do this.

I have a custom integration with traefik+Let's Encrypt documented here - https://github.com/EnigmaCurry/kubelab

On Sun, Jan 6, 2019, 10:04 PM Sonam Samdupkhangsar <[email protected] wrote:

Does DigitalOcean Kubernetes have the ability to use lets encrypt to use a domain name with https? There are docs online but not sure if there is an update or examples on how to do this.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/digitalocean/digitalocean-cloud-controller-manager/issues/92#issuecomment-451822863, or mute the thread https://github.com/notifications/unsubscribe-auth/AACoNcGfT4xAQCQ7wQnDcurrYt5ZW_QEks5vAtVJgaJpZM4T4LVS .

Just to make sure, are you looking for the ability to utilize Let's Encrypt Certificates on DigitalOcean loadbalancer for Kubernetes? I had been delaying a project of mine because of this, but I found out that it is already baked into the loadbalancer that is pointing at my cluster. If you select HTTPS ingress, it just asks for which certificate to use exactly as it would for a non-kubernetes pointing loadbalancer!

I have a chicken and egg problem with this that i don't know how to fix unless the LE inttegration is there?

The LB needs to have the cert ID added as an annotation but I don't know the IP of the LB until it is created.

How are people getting around this?

@wayne-o I gave up on this entirely and set up an nginx ingress controller and cert-manager to handle it instead.

I think I am going to do the same. On 25 Feb 2019, 12:26 +0000, Nick Pack [email protected], wrote:

@wayne-o I gave up on this entirely and set up an nginx ingress controller and cert-manager to handle it instead. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

With godo now supporting Let's Encrypt, it should be possible to make the necessary extensions to CCM. I haven't had the bandwidth to push this myself, though. If any volunteer would like follow up on the discussion that started earlier in this issue and take a stab on a PR, however, I'd be happy to assist and review.

One thing I noticed is that a user can specify a Let's Encrypt certificate ID by annotation. For example:

"service.beta.kubernetes.io/do-loadbalancer-certificate-id" = "234h23h32-2244-4jk4-k4723-72b2f36ce721"

I'm currently doing this with a service of mine.

However - when a Let's Encrypt certificate expires, the certificate ID in DO's system changes. DO is currently "smart" enough to update the load balancer with the new certificate - but does one need to worry about having to update their Kubernetes Service definition too?

The problem is the certificate update occurs in an automated fashion prior to certificate expiration. This is great - the cert won't expire, but you don't know when it's going to happen.

@acejam apologies for the late response.

The issue you describe about LE certificates being updated automatically for LBs but not for Services is indeed a problem. We have started work on PR 274 (link right above this message) that is going to address the problem.

/cc @waynr @snormore