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

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

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

 

What is Cert-Manager?

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 a 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 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 both 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.

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 constant 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.
  • ClusterIssuer is 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 ClusterIssuer for information on how to obtain the certificate.

Setting Up Cert-Manager

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 url like the following:

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

This Ingress points to a custom Service and return 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.

 

A Step-by-Step On 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 a 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 jetstack https://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:

kubectl apply -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: devops@kruschecompany.com
    # 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 – name of Secret which contain PrivateKey for ClusterIssuer and it will be crearted automatically.

And that’s it, your Kubernetes cluster ready for obtaining Let’s Encrypt certificates. For creating certificates manually we should use 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

secretName – this Secret contain certificate which should be used in Ingress. It will be created automatically.

Where:

commonName – main domain name
dnsNames – alternative domain name ( SAN )

For automated certificate generation, you should add a 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

Where:

secretName – this Secret contain certificate which should be use in Ingress. It will be created automatically.

 

Kommentar hinzufügen

E-Mail-Adresse ist schon registriert. Bitte benutze Das Login-Formular oder nenne eine andere.

Du hast einen falschen Nutzernamen oder Passwort eingegeben

Sorry that something went wrong, repeat again!
Kontaktieren Sie uns