How-To: Automatic SSL Certificate Management for your Kubernetes Application Deployment

Jaroslav Pantsjoha
Oct 24, 2019 · 12 min read

A bit of the Same, But Different. We deployed the app, but Let’s ensure our SSL Certificate is managed automatically for our Application Deployment.

Welcome back, or welcome for the very first time. This Security themed post will take the example of the previous blog post, “How-to: Kubernetes Application Deployment with DNS management” — which exemplifies the relative simplicity in application deployment with automatic DNS management, and takes it to the next “production-closer” level.

Let’s ensure such an application deployment process is matched with the SSL certificate. This post will lead it’s way into the GitOps deployment methodology again. The purpose of which is to codify your infrastructure, store it in Git and let the likes of Weaveworks Flux (https://github.com/fluxcd/flux) deploy it automatically, and in full.

Your System Requirements

This may be obvious, but you will need git, google-cloud-sdk and kubectl installed on whichever system you are running this.

As I do intend the hands-on number of your readers to be able to duplicate the success, so do ensure you read the First Blog Post, which outlines the Google DNS zone requirement and the follow-up application configuration, from here. The full code example with yet-another DNS zone, but the same service configuration, with yet full working code example, is found on my own bitbucket.

There is a number of dependencies to get this off the ground, to reproduce this, you will require to ensure the following checklist is in order;

  • Your Google Cloud DNS zone is setup
  • Kubernetes Cluster is created
  • Kubernetes Demo Application is running from the previous post.
  • Get ready to start pasting more…

Where were we

Before getting into the meat of this, let’s fast forward this dependency prep formality.

DNS ZONE is the same as before.

I’ve deployed the same Kubernetes cluster, via Google Cloud gcloud cli utility.

FROM

TO

Deploy the very same Demo Nginx App, Ingress, and the DNS Manager;

Verify. Same old, same old.

This does get some (little) amount of time to get DNS records propagated throughout, — taken me closer to 10 minutes to finally see it work here.

SSL Manage This

Now that the environment setup and formalities are out of the way with the prereqs, let’s get to the bit what you came here for — Let’s get this under SSL Certificate and auto-manage this toil! This is a SSL Certificate for GKE Ingress — a GCP Cloud Provider-based Demo.

There are key points worthy to go-over for this particular cert-manager demonstration;

  • I am using the Let’s Encrypt Certificate Authority for this demo. There are a few to choose from.
  • I am using the DNS01 validation, there are other methods like http01 possible
  • My demo is based on the GCP platform and the relevant service-account access control setup is required.

The documentation on the cert-manager website is quite handy, but it is the usual case of piecing-up all the components together to get it to work, particularly https://docs.cert-manager.io/en/latest/tutorials/acme/dns-validation.html

Go Time. Let’s get our public-facing Nginx App Certifi’ca’ted with SSL certs.

Apply the cert-manager YAML to your cluster. You need is to deploy the latest-greatest cert-manager latest, straight into Kubernetes environment. (https://docs.cert-manager.io/en/latest/tutorials/venafi/securing-ingress.html#installing-cert-manager)

FROM

TO

This will create the namespace with all the dependencies ready to go. Now, as you’d expect we have to get a few things in order.

HouseKeeping Vars

Setup the GCP Service Account & Secret KEY
This will address the Kubernetes-context Cert-Manager managing that DNS zone, as that would work via the dedicated service account.

Create that K8 context Service Account secret to be used with the Cert-Manager.

This will create something along the lines of

Create Cluster Issuer

These represent a certificate authority from which signed x509 certificates can be obtained, such as Let’s Encrypt, or your own signing key pair stored in a Kubernetes Secret resource. They are referenced by Certificate resources in order to request certificates from them. (https://docs.cert-manager.io/en/latest/tasks/issuers/index.html)

I have gone for the ClusterIssuer type so my certificates are managed for the global scope of the Kubernetes Cluster, not a particular namespace if it were a mere Issueralone. (https://docs.cert-manager.io/en/latest/reference/clusterissuers.html)

ClusterIssuers are a resource type similar to Issuers. They are specified in exactly the same way, but they do not belong to a single namespace and can be referenced by Certificate resources from multiple different namespaces.

FROM

TO

Create your Initial Certificate

As the name suggests, let’s request that certificate. Here we essentially have a CSR ‘form’, with the validation type. DNS01 is the validation method of choice. Coupled with the External-DNS service we have running on this Kubernetes cluster, this method should provide the automated Certificate setup and on-going renewal management.

FROM

TO

Create Ingress to use that certificate, or update existing ones.

This is down to choice, we can update the existing ingress and have the annotation `kubernetes.io/ingress.allow-http: true` to ensure it’s backward compatible.

FROM

TO

Our Services and Ingress Console view, after all these configurations, should look like this;

Waiting Game commences. Despite the seemingly complete configuration, the immediate result is that the cert-manager generated a self-signed certificate. This is a temporary certificate until it gets signed by the CA (Let’s Encrypt)

We can tail the log from the cert-manager, as well as view the zone record.

Waiting for the auto-generated DNS01 challenge to be approved — DNS propagation wait

What is happening there?
-
Cert-Manager will discover the certificate requirement across the cluster (from ingress definitions)
- Cert-Manager will the automatically create the DNS challenge (you can view your DNS zone)
- Cert-Manager will then match/self-solve that DNS challenge, and issue a temp certificate
- Cert-Manager will get the designated CA (Let’s Encrypt) to sign it, to make it all official and ‘permanent’
- Cert-Manager will repeat this on every renewal date (every 3 months with Let’s Encrypt)

Curl and OpenSSL validate the results, with;

Curl-tested, OpenSSL-reviewed, let’s get that screenshot as well, shall we;

Result.

There.
Saved you a lot of manual effort and your application communication is secure. Time for Beers?

If you enjoyed this post and want to see more end-to-end Kubernetes demos, please clap and share the post

See you in the next post,
JP

PS There is a host of exciting Kubernetes projects taking place at Contino. If you are looking to work on the latest-greatest infrastructure stack or looking for a challenge, — Get in touch! We’re hiring!

We’re looking for bright minds at every level. At Contino, we pride ourselves on delivering the best practices cloud transformation projects, for medium-sized businesses to large enterprises.

JP

Contino Engineering

Opinions from Contino Engineering

Jaroslav Pantsjoha

Written by

All About engineering efficient infrastructure solutions by day and An Equity and The Blockchain investor by night.

Contino Engineering

Opinions from Contino Engineering

More From Medium

More from Contino Engineering

More on Kubernetes from Contino Engineering

More on Kubernetes from Contino Engineering

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade