Let's Encrypt managed TLS certificates in Kubernetes (GKE)

October 3, 2019

Securing the web application Internet traffic is one of the most common activities as the HTTPS is a must nowadays. Let’s Encrypt is becoming the most commonly used Certificate Authority providing the ability to automate the certificate issuing and renewal using ACME protocol.

With growing Kubernetes (K8s) popularity, the web applications hosted in such environment meet the same requirements, but face different challenges; mostly due to not-so-trivial configuration and complicated certificate renewal.

If you are using Google Kubernetes Engine (GKE) on Google Cloud Platform (CGP), it is possible to use managed Google TLS service to automate the TLS provisioning and certificate renewal.

It’s important to mention though that such implementation is vendor (Google) specific and might result in the vendor lock, so keep that in mind.

Also, this service is currently in Beta stage, so it has some limitations and potential issues.

The workflow of using the managed TLS certificates is relatively simple:

The K8s ManagedCertificates object structure is the following (real world example from my blog):

apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
  name: lescinskas-lt-cert
  - lescinskas.lt

The object is created as usual in K8s - using kubectl apply.

If you need to configure the Ingress controller with multiple domains, each (sub)domain needs to be set up as a separate object (current service limitation).

After setting the ManagedCertificates up, the annotation needs to be added to the Ingress configuration and applied as usual:

apiVersion: "extensions/v1beta1"
kind: Ingress
  name: "lescinskas-lt-ingress"
    networking.gke.io/managed-certificates: "lescinskas-lt-cert,www-lescinskas-lt-cert"

Certificate objects are listed using comma as the separator. In this example I use both lescinskas.lt and www.lescinskas.lt domains to expose this website to the Internet.

During the provisioning the HTTPS version of the website will return various errors:

This should get automatically fixed within 10-20 minutes.

This is tolerable for new HTTPS setups, however for the web applications that already have some manual HTTPS configuration, such migration to this service will result in the certain downtime.