I'm currently trying to set up a highly available LDAP server configuration in Kubernetes. The challenge I'm facing is that these LDAP servers need to communicate securely with each other via TLS, but they're using internal cluster DNS names. Unfortunately, this means that I can't obtain valid Let's Encrypt certificates. I'm looking for guidance on how to establish secure and trusted communication in this setup, ideally in an automated way. Any suggestions would be greatly appreciated!
4 Answers
I've got a few ideas. First off, consider your threat model—what are you trying to protect against? Also, could your LDAP have an external DNS name (like myldap.companyname.com)? You could generate a certificate for that name and use it internally while hairpinning your traffic. Finally, you might explore service mesh solutions like Istio that can offer mTLS support as part of the stack.
Why not just create proper names for your services that resolve through a DNS server you control, both internally and externally? That would allow you to use Let's Encrypt certificates through DNS-challenges.
You could set up a self-signed issuer using cert-manager. Then, with trust-manager, you can create certificate bundles that include the CA certificate of your issuer. Just make sure to use that bundle (as a configmap holding all the public certs) on the pods needing them.
I recommend using Smallstep CA, which supports the ACME protocol. You’d need to deploy it and create your own CA. After that, share the CA certificate in cert-manager, and create a ClusterIssuer that will use the Smallstep CA URL for issuing the certificates. Just a heads-up, it only supports HTTP-01 validation but it works well for internal setups.
Actually, dns-01 is supported by step-ca too, just so you know!
Exactly! Or you could also consider stuffing the certificates into each node. Some platforms, like AKS, have options to add certificates to nodes seamlessly.