This post is the final installment of a three-part series highlighting an easy path forward for operations teams that need to up their certificate-management game for Kubernetes. The first entry covered the tools you can use for automated certificate management. The second entry deployed the Harbor container registry with an SSL endpoint to show the tools in use. This final entry summarizes two alternatives to using the Let’s Encrypt certificate authority, which was discussed in the two previous blog posts. These alternatives may work better with your existing certificate workflow and help improve developer velocity and production robustness.
Two potential alternatives
If you’re using an internal certificate authority (CA), you can leverage it in cert-manager. This approach gives you automatic certificate management in Kubernetes using your CA instead of Let’s Encrypt. Although using your own CA adds a little extra maintenance to your existing certificate management, it allows development to keep a higher velocity. The two options can be weighed based on whether you want to, or are able to, leverage Vault by HashiCorp for secret management.
Option 1: Use an intermediate CA and Vault in cert-manager
This option is great if you need to operate many Kubernetes clusters because one intermediate CA can feed many Kubernetes clusters with certificates. You’ll need to run Vault where it can be reached by all the clusters it needs to sign certificates for. Then you need to create an intermediate CA and store it in Vault. You’ll then configure cert-manager in each cluster to use the Vault instance as an issuer. Finally, remember to renew the CA in the Vault on schedule. Developers will create ingress resources as before, but now they will reference the Vault issuer instead of the Let’s Encrypt issuer.
Look at the cert-manager documents to see an example of using the Vault issuer.
Option 2: Use an intermediate CA directly in cert-manager
This option is good if you want to avoid adding a new component to your platform or if you have few Kubernetes clusters. You’ll create an intermediate CA for each cluster and store the certificate and key as a secret in each Kubernetes cluster. I recommend against using the same intermediate CA in more than one cluster. Then you’ll configure and use the CA issuer in cert-manager for each cluster. Finally, remember to renew each of these cluster CAs using your existing certificate workflows.
Look at the cert-manager documents to see an example of using the CA issuer.
Potential Gotchas
Here are some things that could trip you up:
- If using Let's Encrypt, as we did in prior posts, you may hit rate limits using the production issuer. Always test using the staging issuer until you have the ingress resource correct.
- Failing to update DNS records to point to your ingress external IP address or load balancer address will result in cert-manager being unable to prove that you own the domain name, so it won’t issue a certificate.
If you’re still hitting problems, check the troubleshooting guide.
Summary
This entry closes out the series on certificate management for Kubernetes services. In this final entry, we covered a couple of use cases that may better match your existing certificate management workflow. Hopefully, this series has been helpful as you start to manage Kubernetes clusters for your developers.
As a parting request, I ask you to look into how Let’s Encrypt can be used to automate certificate management for non-Kubernetes services. Imagine what you can do with the time this project would free up.
