kubernetesrancherlets-encrypt

Rancher 2x and Let's Encrypt

calendar_month July 15, 2019

Update (November 2019): Since November 1, 2019, certificates from Let’s Encrypt can only be issued with cert-manager > 0.8.x. Therefore, the current version of this article is obsolete, as the installation mentioned here only includes version 0.5.2. Rancher has not released a Helm chart update for this. Currently I’m writing an article on how to work around this issue. I will then update this article.

This article – Rancher 2x and Let’s Encrypt – was extracted from “Kubernetes easily with Rancher: Cluster (Part 4)” to preserve overview and readability in both posts.

Those who have read all articles in the Kubernetes easily with Rancher series can continue. Everyone else is advised to work through the other articles first.

The goal is to provide both manual and automated requesting and creation of a Let’s Encrypt certificate for our cluster.

Prerequisites

  • Your own domain
  • Ability to create a DNS entry pointing to the cluster
  • Rancher Kubernetes cluster (we should have this)

For the example in “Rancher 2x and Let’s Encrypt”, I created a subdomain and pointed it to my cluster.

Cert-Manager

We deploy the Cert-Manager via a Helm chart. To do this, we switch to the “system” project and select “Apps” from the navigation.

After clicking “Launch”, the catalog view opens. Here we must enter the name of the Helm chart in the top right, for example “cert”.

Now we should select the cert-manager chart from the standard catalog. We click on “View Details” which takes us to the deployment form.

The intended cert-manager instance must be declared as “Default Cluster Issuer”. Additionally, the “letsencrypt-prod” client should be selected – otherwise we’d have to repeat these steps.

The created certificates are registered with an email address, so the conscientious user should enter their actual address here.

By clicking “Launch”, the deployment begins.

As soon as the deployment is complete, we can use the cert-manager.

Rancher cert-manager: Simple Example

So far so good, now a simple example follows for illustration. We create a simple workload, then we let Ingress – basically a publication – automatically request a certificate from Let’s Encrypt.

Rancher Workload

For tests I use the “Labs” project, keeping the other projects clean. For this example in “Rancher 2x and Let’s Encrypt” I use Labs, which is how the example is fully executed. Under Workloads we click “Deploy”.

This takes us to the “Deploy Workload” view. Name and namespace can be freely chosen; under “Docker Image” we enter the image name including tag – in our case nginx:alpine.

Additionally, we need to add a port mapping – Port 80/TCP → Cluster IP. By clicking “Launch”, our workload (1 Pod and 1 Service) is provisioned.

Rancher Ingress

Now comes the exciting part: creating an ingress entry. To do this, we switch to the “Load Balancing” tab and click “Add Ingress”. In the new form, we now enter the required information.

Name and namespace can be freely chosen, while under “Rules” “Specify a hostname to use” should be selected and set to the intended domain – in my case ssltest.ak8s.de.

The pre-filled Target Backend entry must be deleted, as it points to a workload but we want to reference the service.

Then we click “+Service” and point the root path to the service on port 80, then click “Save”.

Unfortunately, we’re not done yet. With the save, the standard annotations and labels for our ingress are now set. We could have set these ourselves, but then we could have done the whole example in YAML.

After successful ingress deployment, the standard Nginx greeting page should appear when calling the URL – in my case http://ssltest.ak8s.de. So far only over HTTP. We want SSL, i.e. HTTPS instead. To do this, we need to edit our ingress and add the required annotations, then apply them with “Save”:

  • kubernetes.io/tls-acme: "true"
  • certmanager.k8s.io/cluster-issuer: letsencrypt-prod

Final Steps

Now comes the final step. We need to edit the YAML of our ingress. To do this, we click the three dots in the Load Balancer view and select “Edit YAML”.

For the certificate, Rancher needs a name, which is stored under “Resources → Certificates”. That’s why we need to adjust our YAML.

Directly under tls.hosts, we create a new line and add an entry (in my case secretName: ssltest-ak8s-de-crt). The created certificate will be stored under Certificates with this name.

If everything ran without errors, we can now call our site via HTTPS.

This whole procedure can be avoided by relying on YAML files. Usually, the configuration can be passed along with most Helm charts. This example is interesting in that you’ve at least done it yourself through the UI once.