Cert-Manager: Automated Certificate Management For Kubernetes – Free Your Engineers

An introduction to Cert-Manager for Kubernetes and step-by-step set-up guide

Cloud • UPDATED ON December 7, 2021

John Adam

Author

What is Cert-Manager for Kubernetes?

In this post, we’ll address the utility offered by the cert-manager automated certificate management tool for Kubernetes, what it does, the output of that functionality. And we document a step-by-step guide to cert-manager set-up and configuration.

Cert-manager, an open-source jetstack.io project, is an ISA x509 certificate management controller native to Kubernetes. As an automation tool, cert-manager reduces the ‘routine work’ load on engineers, allowing highly paid experts to focus on where they can add the most value. It simplifies management, issuance and the renewal of certificates, securing application traffic – a critical function in the contemporary web. Automating the certification process saves engineers time as well as improving security by negating the risk of human error.

Cert-manager follows on from kube-lego,  jetstack.io’s original Let’s Encrypt certificate provisioning tool for Kubernetes Ingress resources. Kube-lego simplifies the securing of traffic between your users and your cluster ingress point. But limitations of building a controller only around Kubernetes Ingresses have become clear.

Cert-manager has been built around Kubernetes CustomResourceDefinitions, which has led to significantly more flexibility around configuration. Debugging capabilities are also improved upon and now support a broader range of CAs than Let’s Encrypt as a stand-alone tool.

When should you use cert-manager certificate automation?

A good example of the strengths of employing cert-manager certificate automation would be a web-based application whose user-facing interface, API, admin front and admin API are all hosted under separate domain names. This means each service requires its own individual certificate. The Cert Manager monitors the timing of these certificates and renews them if and when necessary.

When dynamical environments are used in the development process (a feature is written, the next dev environment created, tested and the environment deleted) SSL certification need to be constantly generated. As a manual process, that’s a lot of expensive work-hours. But if a ‘heart manager’ is set up, it will generate all necessary certificates automatically without any engineer involvement. This is particularly beneficial in the case of larger web-based applications. In the case of an example of 20 services, automating certification using cert-manager could potentially save a very significant amount of manual engineer work.

Cert-Manager Components

• Issuers represent a certificate authority from which signed x509 certificates can be obtained, such as Let’s Encrypt– jetstack.io’s certificate provisioning tool for Kubernetes Ingress resources.
• ClusterIssueris a resource type similar to Issuers. It is specified in exactly the same way, but it doesn’t belong to a single namespace and can be referenced by Certificate resources from multiple different namespaces.
• Certificate is a namespaced resource that references an Issuer or ClusterIssuerfor information on how to obtain the certificate.

Setting Up Cert-Manager: a step-by-step tutorial

The first step to setting up cert-manager is to install custom CRDs – ClusterIssuer, Certificate, Order and Challenge. Cert-manager is then installed via Helm.

Helm helps manage the required state of multiple Kubernetes objects. Its effectiveness is optimised when paired with Reckoner, which uses a YAML syntax to install multiple Helm releases at once, and facilitates the installation of charts from a git repository.

A new object Certificate is then created and Cert-manager subsequently creates Order with CSR and Сhallenge, using Order to obtain new a certificate.

To obtain new certificates Cert-manager creates a separate Ingress with a URL like the following example:

http://main.domain.com/.well-known/acme-challenge/SFAHjkfhkj2hjkn23kbk32nknkfn3ktk3j4gkj3b .

This Ingress points to a custom Service and returns a hash for certificate validating. In parallel, cert-manager creates a self-signed certificate until the main certificate is obtained.

All of these certificates (temporary and main) are stored in Secret and used in Ingress config.

After obtaining a valid certificate, cert-manager places this certificate in Secret in place of the temporary certificate, deleting also the temporary Ingress and Service.

How To Install Cert-Manager

Create a custom CRD

kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml

Create and label namespace for cert-manager

kubectl create namespace cert-manager
kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true

Add helm repository for using latest helm-chart

helm repo add jetstackhttps://charts.jetstack.io
helm repo update

Install Cert-manager helm-chart

helm install –name cert-manager –namespace cert-manager –version v0.9.1 jetstack/cert-manager

Create ClusterIssuer

Cert-manager could obtain certificates in a different CA. For example, let’s see how it works with Let’s Encrypt:

kubectlapply -f letsencrypt-clusterissuer.yaml

letsencrypt-clusterissuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1

kind: ClusterIssuer

metadata:

name: letsencrypt-cluster-issuer

spec:

acme:

# The ACME server URL

server: https://acme-v02.api.letsencrypt.org/directory

# Email address used for ACME registration

email: [email protected]

# Name of a secret used to store the ACME account private key

privateKeySecretRef:

name: letsencrypt-prod

# Enable the HTTP-01 challenge provider

http01: {}

Where:

privateKeySecretRef.name – Secret which contains the  Private Key for Cluster Issuer and it will be created automatically.

And that’s it, your Kubernetes cluster ready for obtaining Let’s Encrypt certificates. For creating certificates manually we should use the next config:

Certificate.yaml

apiVersion: certmanager.k8s.io/v1alpha1

kind: Certificate

metadata:

name: test-cm.krusche.cloud

namespace: default

spec:

secretName: prod-cert-nginx

issuerRef:

name: letsencrypt-cluster-issuer

kind: ClusterIssuer

commonName: test-cm.krusche.cloud

dnsNames:

- test-cm.krusche.cloud

acme:

config:

- http01:

ingressClass: traefik

domains:

- test-cm.krusche.cloud

Where:

secretName – this Secret contains a certificate that should be used in Ingress. It will be created automatically.
commonName- main domain name
dnsNames- alternative domain name ( SAN )

For automated certificate generation, you should add the next annotation to Ingress config:

Ingress-example.yaml

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: nginx

annotations:

kubernetes.io/ingress.class: "traefik"

certmanager.k8s.io/cluster-issuer: "letsencrypt-cluster-issuer"

kubernetes.io/tls-acme: "true"

certmanager.k8s.io/acme-challenge-type: "http01"




spec:

tls:

- hosts:

- test-cm.krusche.cloud

secretName: quickstart-example-tls-5-prod

rules:

- host: test-cm.krusche.cloud

http:

paths:

- path: /

backend:

serviceName: nginx

servicePort: 80

secretName – this Secret contains a certificate that should be used in Ingress. It will be created automatically.

Your cert-manager should now be all set up on Kubernetes ready to start automating certificate management.