6 ms·

It's kind of ridiculous internal load balancers can't get automatic certs. We've had to do a stupid dance just to get certs via the LE DNS challenge out of band

by lvh 7y ago

It's kind of ridiculous internal load balancers can't get automatic certs. We've had to do a stupid dance just to get certs via the LE DNS challenge out of band, and then regularly install them on internal LBs.

tmpz22 7y ago
Same! I still manually provision some certificates just because LEGO/etc. just don't work with GCP + Google Cloud Load balancer! And the docs for the entire subject are useless..
rolleiflex 7y ago
We paid for long-lasting wildcard certs because of that. Which Apple killed a few days ago. It’s going to be fun when they are close to expiry.
zomglings 7y ago
Does cert-manager not for your needs? https://github.com/jetstack/cert-manager https://github.com/jetstack/cert-manager
- tmpz22 7y ago
  > As this project is pre-1.0, we do not currently offer strong guarantees around our API stability. Notably, we may choose to make breaking changes to our API specification (i.e. the Issuer, ClusterIssuer and Certificate resources) in new minor releases.
  - yebyen 7y ago
    In practice, the cert-manager team has made breaking changes in probably close to 1/3 of minor releases (which is really fine pre 1.0, IMHO), there has been comprehensive guidance to lead users or cluster admins through upgrading, that walks through exactly what steps are needed, and followed well does not interrupt your cluster's service in any way. It's not dark magic, it might make building off of it in the form of integrations prohibitive, but they have done a great job making sure users can upgrade one release to the next. It is a little bit of a treadmill, but it certainly beats manually renewing certificates!
hitpointdrew 7y ago
Maybe I don't understand your problem, but can't you just use Traefik (https://docs.traefik.io/user-guides/crd-acme/ https://docs.traefik.io/user-guides/crd-acme/). It will get certs from letsencrypt for you.
- lvh 7y ago
  Key word: "internal" -- these aren't on the internet, Traefik does ALPN, which means the LB itself has to be on the Internet. (Or something else that leaks the cert to the LB, but that doesn't sound any less complicated than using the DNS challenge.)
- jrockway 7y ago
  TCP coming into your cluster means that you practically have to go through kube-proxy (because the load balancer and the Kubernetes scheduler aren't perfectly synchronized) and that the load-balancer can't balance per-request, only per-connection. If the load balancer terminates TLS, then it can just watch cluster endpoints and automatically route to the right node without any extra hop through kube-proxy, and it can also split large individual requests out of HTTP/2 and GRPC streams. I'm guessing 99% of workloads won't notice either of these issues, but it is an actual issue.

by lvh 7y ago

tmpz22 7y ago

Same! I still manually provision some certificates just because LEGO/etc. just don't work with GCP + Google Cloud Load balancer! And the docs for the entire subject are useless..

rolleiflex 7y ago

We paid for long-lasting wildcard certs because of that. Which Apple killed a few days ago. It’s going to be fun when they are close to expiry.

zomglings 7y ago

Does cert-manager not for your needs? https://github.com/jetstack/cert-manager https://github.com/jetstack/cert-manager

tmpz22 7y ago
> As this project is pre-1.0, we do not currently offer strong guarantees around our API stability. Notably, we may choose to make breaking changes to our API specification (i.e. the Issuer, ClusterIssuer and Certificate resources) in new minor releases.
- yebyen 7y ago
  In practice, the cert-manager team has made breaking changes in probably close to 1/3 of minor releases (which is really fine pre 1.0, IMHO), there has been comprehensive guidance to lead users or cluster admins through upgrading, that walks through exactly what steps are needed, and followed well does not interrupt your cluster's service in any way. It's not dark magic, it might make building off of it in the form of integrations prohibitive, but they have done a great job making sure users can upgrade one release to the next. It is a little bit of a treadmill, but it certainly beats manually renewing certificates!

hitpointdrew 7y ago

Maybe I don't understand your problem, but can't you just use Traefik (https://docs.traefik.io/user-guides/crd-acme/ https://docs.traefik.io/user-guides/crd-acme/). It will get certs from letsencrypt for you.

lvh 7y ago
Key word: "internal" -- these aren't on the internet, Traefik does ALPN, which means the LB itself has to be on the Internet. (Or something else that leaks the cert to the LB, but that doesn't sound any less complicated than using the DNS challenge.)
jrockway 7y ago
TCP coming into your cluster means that you practically have to go through kube-proxy (because the load balancer and the Kubernetes scheduler aren't perfectly synchronized) and that the load-balancer can't balance per-request, only per-connection. If the load balancer terminates TLS, then it can just watch cluster endpoints and automatically route to the right node without any extra hop through kube-proxy, and it can also split large individual requests out of HTTP/2 and GRPC streams. I'm guessing 99% of workloads won't notice either of these issues, but it is an actual issue.