As more and more solutions are built using microservices architecture, it is very important to have all your public endpoints encrypted. The good news is that you can achieve it without spending any additional penny. LetsEncrypt is one such project which is a free and open Certificate Authority and you can easily integrate it with your setup to automatically generate SSL certificates free of cost, FOREVER...
In this article I'll explain how you can setup LetsEncrypt with cert-manager on Kubernetes. I've used Route53 for this demonstration and cert-manager version 0.12. This process is applicable for any flavor of Kubernetes be it bare-metal, EKS, GKE or AKS. I'll be using ACME issuer with DNS validation method. Let's dig in.
Please ensure you have following setup properly configured before working on LetsEncrypt setup.
Now follow the step by step instructions to configure letsencrypt and cert-manager on Kubernetes.
Install the CustomResourceDefinition resources. These are those resources which are not available by default but can be created by extending the Kubernetes API.
Create namespace for cert-manager.
Add the Jetstack Helm repository and update your local Helm chart repo cache.
Install the cert-manager Helm chart
Now verify that cert-manager pods are created and wait for all of them to be in running state.
Create an IAM user and attach following policy to get access to Route53 zones. If your entire setup is on AWS then you can use IAM role as well. But if you're using Kubernetes cluster outside AWS but using only Route53 then you can use IAM user.
Attach the following policy to the user and keep a note of AWS ACCESS KEY and SECRET ACCESS KEY.
Create a secret in cert-manager namespace which contains the SECRET ACCESS KEY. Save the secret key in the file called secretkey.
It will create a secret called acme-route53 in the cert-manager namespace. Make sure you delete the file secretkey
Create a resource of type ClusterIssuer which will be used to issue certificates. Let's create it in the cert-manager namespace for better management. Although the namespace doesn't matter because ClusterIssuer resource is applicable to all the namespaces in the cluster.
Now take a look at status of this resource.
Above output confirms that it is ready for use. If the status shows 'False' here then check the logs of 'cert-manager-6bcc9d894d-d7s9j' pod to troubleshoot.
Once we have our issuer setup, let's create a new certificate. It will take around 2-3 minutes as it first verifies the domain name by creating a recordset.
Above manifest will create a certificate by name 'nginx-tls' in the namespace you specify. Please do modify the DNS name as you provided while creating the ClusterIssuer.
Let's verify the status of the certificate.
Above output confirms that your certificate is ready to use.
Above setup is all you need to configure a fully functional certificate generation process. Next step is to bind this certificate to your Ingress controller. Here is a sample Ingress manifest for reference. You can modify relevant parameters for your own deployment.
Setup of Ingress controller is beyond the scope of this article. Please follow relevant articles of the cloud providers you're working on. Take a note of the annotation for cluster issuer resource name and the secretName under tls section.
If all goes well then you'll be able to see a fully valid certificate associated with your domain and you don't have to worry about the renewal as well.