This is a part of the series of posts on Getting an API running in Kubernetes. For this to make sense you should have worked through a few of the earlier examples. This uses kube-leo which is being deprecated in favour of cert-manager. You can read how to use cert-manager instead here

I recommend that you save your commands in various scripts so you can repeat them or modify them later.

In this article – we’re doing this.

SSL

Before you can secure access to your service and run it over HTTPS, you’ll need to generate a certificate and certificate key. Working with certificates is horrible, and causes brain freeze in many people – including me. Luckily we have 3 things to help us.

  • Letsencrypt allows you to get free certificates (normally you’d have to pay for them).
  • Kube-lego is a set of Kubernetes components that can manage the whole business of renewing and applying those certificates and is available as a helm-chart. Kube-lego has been superseded by cert-manager, but it’s a lot simpler, so we’ll stick with that one.
  • Kubernetes can store secrets and they can be accessed by other cluster resources.

Kube-lego

You should already have helm installed from Bringing up an ingress controller, but if you don’t – that’ll do it.

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash
helm init

Next, install kube-lego, changing the email address to yours. Note I’m installing this in the kube-system namespace. kube-lego can work across namespaces – so it could be handy in other work in this cluster.

make-lego.sh

echo "start up  kubelego"
helm install stable/kube-lego --namespace kube-system --set config.LEGO_EMAIL=bruce@mcpher.com,config.LEGO_URL=https://acme-v01.api.letsencrypt.org/directory

If you hit a permissions problem with the deployment itself, you can try appending this to the helm install line. If you get problems with tiller permissions see Bringing up an ingress controller for how to deal with it.

--set rbac.create=true

You should see a deployment for kube-lego


As well as a service

What does kube-lego do

It searches for ingresses (not ingress controllers) that have a specific annotation (more about what that is later)

metadata:
 annotations:
   kubernetes.io/tls-acme: "true"

and creates and manages letsencrypt certificates for them, storing them as Kubernetes secrets. If you check the log of the kube-lego pod, you’ll see how it does that. An annoyance with letsencrypt is that their certs expire after 90 days. Kube-lego takes care of that too by automatically renewing them if they look like they’ll expire.

Annotations

You may have noticed “annotations” in some of the .yaml configurations. These are markers that can be read by other Kubernetes resources. The next step is to create an ingress for our service that will contain an annotation like the one above to let kube-lego know that it needs to be processed for a certificate.

  • The ingress controller checks for annotations in the configuration of ingresses to see if it should handle them
  • Kube-lego checks ingresses for the tls-acme annotation to see if it needs to manage certificates

Next step

Nearly done – next step is the final piece of the puzzle. The ingress to connect the service to the ingress controller and to signal to kube-lego it needs to be managed.

Why not join our forum, follow the blog or follow me on Twitter to ensure you get updates when they are available.