Hey everyone, I'm tackling a challenge with our high-availability LDAP server setup running on Kubernetes. The servers communicate via TLS using internal cluster DNS names, which makes it impossible to obtain valid Let's Encrypt certificates. I'm looking for suggestions on how to establish secure and trusted communication in this context while keeping the process automated. Any guidance would be appreciated! Thanks!
4 Answers
Why not just set proper names that resolve to an internal and controllable name server? That way, you could use the DNS challenge method from Let's Encrypt to acquire certs for those names!
I’ve had success using Smallstep CA, which supports the ACME protocol. You just deploy it and create your own CA. Then you can share that CA certificate with cert-manager and create a ClusterIssuer that uses the Smallstep CA URL to issue certificates. It’s essential to note that it only supports HTTP-01 validation, but it gets the job done!
You could set up a self-signed issuer with cert-manager. Then, use trust-manager to create certificate bundles that include your issuer's CA cert. Make sure to use that bundle (as a configmap containing all the public certs) on the pods that need them. It's a straightforward approach!
Exactly! Or you can also install the certs on each node if that's feasible for you. Some providers like AKS have built-in support for adding certs directly to each node.
A few things come to mind here: what’s your actual threat model? Is there a way to expose a public DNS name for your LDAP (like myldap.companyname.com)? Then you could get a certificate for that name, use it internally with that DNS name, and redirect traffic accordingly. Also, have you thought about using service mesh solutions like Istio? They provide mTLS, which could be a solid part of the solution.
Actually, it’s worth mentioning that dns-01 is supported by step-ca now too, in case that's what you were interested in!