cert-manager

Overview

Who better to explain the ins and outs of cert-manager than the people who made it all happen? So this is it. Your ultimate guide for all things cert-manager. And to kick things off, let’s start with a little history lesson.

Back in 2017, when Jetstack first released cert-manager as an open source project, we always knew we were onto something big - we just didn’t quite realise how big at the time. Fast-forward a few years and cert-manager has surpassed a billion downloads, has collected more than 8,500 GiHub stars, and is an officially adopted project within the CNCF.

We couldn’t be prouder that cert-manager has become the go-to platform for issuing and renewing X.509 certificates from within Kubernetes clusters. And when you think about the overall speed and scope of Kubernetes and OpenShift taking place right now, the popularity of cert-manager has only just begun.

Cloud native technologies are now the defacto standard for net-new applications - and with Kubernetes the undisputed leader for orchestrating containerised workloads - that’s an eye watering number of workloads that need to be encrypted and verified as developer teams work on ever faster release cycles.

Hence the need for this guide.

We won’t be treading on the toes of the cert-manager docs site. That’s your go-to resource for all things technical (installation guides, tutorials etc.). Instead, we wanted to give a strategic overview of how cert-manager can help you secure cloud native workloads now and into the future.

Contents:

1. X.509 certs and machine identities
2. What are containers?
3. Kubernetes 101
4. Why cert-manager?
5. How cert-manager works
6. Cloud compatibility
7. Getting started with cert-manager
8. Common use cases
9. cert-manager and Zero Trust
10. cert-manager and DevSecOps
11. Scale and visibility
12. Additional resources

X.509 certs and machine identities

Before diving into the key benefits of cert-manager, we wanted to start the guide with some context. Starting with machine identities and X.509 certificates.

In cryptography, X.509 is the international standard for public key certificates; a digitally signed document that validates the sender's authorization and name. X.509 certificates come in many forms, but Transport Layer Security (TLS) certs are the most common.

Within the machine identity management space, X.509 certificates are one of the most widely accepted forms of machine identity. And to go a level deeper, within the context of a Public Key Infrastructure (PKI), a machine must be able to present a valid form of machine identity in order to establish an encrypted session with another machine.

And how does a machine go about securing a machine identity?

Well, machine identities are issued by third-party organisations known as Certificate Authorities (CAs). Again, within the context of a PKI, it’s the CA’s job to verify that a person or digital entity is who they say they are.

Our parent company, Venafi, have pulled together a quick 2-minute video that perfectly encapsulates the role that X.509 certificates have to play in securing machine-to-machine workloads.

What are containers?

Containers are another topic we need to get our heads around if we are to truly understand the value that cert-manager helps to provide. And the easiest way to do this is by comparing how cloud native apps differ to legacy systems. The diagram below is a great place to start.

Pre-containers and pre-cloud, applications were hosted on physical servers that were stored within an organisation’s own data centre. Back then, servers would typically run one application at a time as there was no clear way to define resource boundaries. And as you might expect, this approach can become extremely expensive and very difficult to manage over time. Especially when a typical enterprise runs north of 450 applications.

Next came virtualization.

Virtualization platforms like VMware, isolate parts of a server so organisations can spin up what is known as a virtual machine (VM). Once done, VMs would be treated in exactly the same way as a physical server would be. They’re just an abstraction of the underlying hardware. Virtualization was the first step towards better resource utilisation - and although organisations would still need to run various operating systems (O/S) within a server - you could start to deploy various workloads on a single machine.

Now, the modern way to deploy new workloads is through containers. Containers share much of the same logic as virtualization in that they’re an abstraction of hardware - but containers go one step further by abstracting the O/S too.

As described by Docker - one of the leading forces behind containers - containers are a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. In comparison to VMs, containers don’t need you to install multiple versions of an O/S on a single server - making containers extremely portable. They’re not tied to a single machine and can be easily deployed on any type of cloud.

Kubernetes 101

The final and most important piece of introductory content we want to cover is on Kubernetes. Kubernetes is the world’s largest orchestration platform for containerised workloads - with 83% of CNCF members already using it in production. In short, Kubernetes is a centralised management platform that helps ensure that containers are running to their required spec. Helping you scale your applications to keep in line with demand.

We don’t want this chapter to become too technical - but one concept we do need to touch on is clusters. Kubernetes clusters are a set of node machines for running containerized applications. So basically, if you’re running Kubernetes, you’re running a cluster. There are various ways you can setup your Kubernetes clusters to manage containerised workloads, however here are three common examples:

Now, to tie this back to machine identities and X.509 certs.

Whilst cloud native technologies provide developers with the means to build more modern and increasingly efficient apps - the ephemeral nature of these machines means that managing their identities has become somewhat complex. Certificates now need to be issued and renewed at a rate like never before - causing developers and security teams all kinds of potential issues.

It therefore wasn’t a surprise for us to learn that 94% of organisations had experienced a Kubernetes related security incident in the last 12 months. With workload misconfigurations being cited as the most common cause.

Why cert-manager?

Now we’ve taken the time to cover the backstory, it’s quite easy to see how and where cert-manager fits in. With the use of cloud native technologies and Kubernetes only heading in one direction - this has made the management and protection of cloud native machines increasingly complex. Or so it once was thought.

Put simply, cert-manager is a cloud native certificate management tool that automatically issues and renews X.509 machine identities as first-class resource types within Kubernetes. To do this, cert-manager needs to be deployed inside a Kubernetes cluster. Then, once inside, cert-manager can issue and renew certificates for all the machine identities contained within a cluster. No matter how short their lifespan.

Organisations that use cert-manager reduce the likelihood of certificate based outages and protect their workloads by verifying all the machine identities that are contained within a Kubernetes cluster. In an alternative universe without cert-manager, manually finding and configuring TLS certificates is a ridiculously onerous task. And this is the basis of its popularity. The fact that it solves a very real issue that developers are faced with on an almost constant scale.

How cert-manager works

We already know that cert-manager is deployed inside a Kubernetes cluster for the purpose of issuing and renewing X.509 machine identities - but in this section we take a closer look at how it works.

To steal the words directly from the cert-manager project site: cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates. Essentially, cert-manager encrypts cloud native workloads by issuing and renewing certificates that have been obtained as part of a PKI.

In terms of flow, Issuers are a Kubernetes resource that represents a CA. This is the resource type that will generate the signed certificates when a request is made by cert-manager. Whereas Certificates will specify the type of certificate that is required, detailing how long the certificate should be valid for, renewal terms, and the required issuer. Once issued, subsequent certificates will be stored as a Kubernetes Secret.

Obviously there’s various other fields and namespaces that need to be configured in order for cert-manager to work correctly - but for a full checklist, please head to cert-manager doc site.

Cloud compatibility

cert-manager is an open source project that builds on top of Kubernetes to provide X.509 certificates and issuers as first class resource types. Fast-forward a few years and enterprise DevOps teams are deploying cert-manager to production clusters with all the major cloud service providers (CSPs)

• Red Hat OpenShift
• Google Kubernetes Engine (GKE)
• Azure Kubernetes Service (AKS)
• Amazon Elastic Kubernetes Service (EKS)
• VMware Tanzu

Getting started with cert-manager

As the creators of cert-manager, Jetstack is the primary contributor to the open source project and is the primary maintainer of the cert-manager project site.

And to be honest, we’re never going to be able to replicate the level of detail that is available on the project site within this one page overview. And we wouldn’t want to either. This guide is meant to serve as your strategic overview on how to be successful with cert-manager. Although, that doesn’t mean we can’t give you a little helping hand by pointing you in the right direction. After all, if you can’t install or configure cert-manager correctly, it’s hardly going to be a huge success.

That said, here are some useful resources to help set you on your way:

• cert-manager installation guide
• cert-manager issuer configuration
• cert-manager tutorials
• cert-manager FAQs
• cert-manager release notes

Common use cases

cert-manager has received some pretty impressive accolades in recent years. At the back end of 2021 it was included in the ThoughtWorks Technology Radar for the first time, whilst at the start of the same year cert-manager was viewed as being the go-to platform for secrets management within the CNCF End User Technology Report. But what are some of the more practical applications of cert-manager? And why is it being downloaded over a million times each day?

In this section we take a closer look at the various ways cert-manager is being deployed to secure cloud native machine identities.

Securing ingress traffic

One of the more obvious use cases for cert-manager is to secure incoming traffic to your Kubernetes clusters. It just makes sense. You wouldn’t give a stranger the keys to your house - so why should organisations running highly distributed infrastructure give unfiltered access to public facing workloads? They shouldn’t. And it’s incomprehensible to suggest otherwise.

By verifying the machine identities of incoming traffic and adopting one of the core principles of Zero Trust - never trust, always verify - organisations will ensure that their public facing web applications are locked down and tamper resistant.

mTLS protection

Developers often build internal workloads that are not exposed to ingress - but could be susceptible to an attack if a nefarious actor found their way into a related Kubernetes cluster. It’s no longer enough to assume your network perimeter is perfectly secure. We need to secure east-to-west traffic as well as north-to-south.

An mTLS type deployment would typically use cert-manager as the conduit to issue and renew private certs. Whether through Hashicorp Vault, self-signed certs, or ACME - there’s various ways organisations can use cert-manager to extend the underlying principles of zero trust to include internal workloads.

Managing workloads in a service mesh

Almost seen as an extension of mTLS, cert-manager can be used to issue and renew certificates within service mesh zones. But what is a service mesh?

A service mesh is an increasingly popular networking technology that allows organisations to secure connections between the growing number of endpoints within cloud native architectures. To do this, a service mesh will only allow access to services within a microservice architecture that has explicit authorisation to do so. This service-based identity allows an application to seamlessly scale resources to keep in line with demand. And how might a resource identify itself to a service?

You guessed it. TLS certificates.

In short, the cert-manager control plane can be used within service mesh environments to control data flows that require automated protection.

Blueprint for certificate management success

Whilst cloud native technologies offer almost endless potential in terms of operational expenditure and speed-to-market gains - the cloud also represents a chance to act on the lessons learned from the world of on-premise. As such, many organisations view the cloud as an opportunity to avoid vendor lock-in and deploy a multi-cloud approach.

Fortunately, cert-manager is a cloud agnostic, open source solution that can be deployed across all your cloud environments. This allows developer teams to roll out a centralised and fully automated approach to certificate management across cloud native infrastructures.

cert-manager and Zero Trust

As seen by the use cases described above, cert-manager is a certificate management tool that allows an organisation to enact on the founding principles of Zero Trust. Deployed as above, organisations can use cert-manager to secure the machine identities of east-to-west traffic as well as ingress.

With cert-manager, developers can ensure that every workload deployed to your Kubernetes platform is from a legitimate and verified source. This is widely accepted as a best practice container security which developers teams can rely on to ensure they can move fast and secure.

cert-manager and DevSecOps

Another solution space we’d like to touch upon in this guide is DevSecOps.

Now, we won’t go as far to say that cert-manager is your one-stop-shop to achieve DevSecOps enlightenment, but we strongly believe that cert-manager can help developers to deploy best-in-class certificate management processes without slowing them down. With this as a backdrop, if we simply view DevSecOps as the mission to bring security teams and developers closer together, cert-manager can serve as the means to push pre-approved certs to cloud native workloads.

Of course, there will be a myriad of other issues that need to be tackled at the same time - culture, visibility, versioning etc. - but cert-manager can provide organisations with the means to scale a tried and trusted solution type (PKI) to cloud native environments.

Scale and visibility

There’s no hiding that we absolutely adore cert-manager. We couldn’t be prouder that it’s taken developer and cloud native communities by storm and become the go-to tool for issuing and renewing X.509 cert for cloud native environments.

However, that said, we realise that as cloud native environments scale more needs to be done to enforce consistent usage across the enterprise. With the typical enterprise juggling north of 450 applications, our professional services team have lost count at the number of times we’ve seen inconsistent versions of cert-manager running in production, or seen certs issued within Kubernetes clusters that adhere to the issuing developer’s own flavour and interpretation of security.

And to that end we’ve been building something. A central control plane that gives enterprise security teams the ability to define cloud native security policy upfront, whilst giving developers and platform teams the tools they need to keep moving at machine speed.

We call it Jetstack Secure.

We know developers love cert-manager. And we know it does a fabulous job issuing and renewing cloud native machine identities in real-time. However, with the use of cloud native technologies - and Kubernetes in particular - only heading in one direction, this does open up questions around scale.

Typically we see cert-manager and Kubernetes only being used within a small cluster (pun intended) of developer teams inside an enterprise. And without security policy or standardised tooling in place that can keep pace with automation- developers will be ones to make the tooling technology choices and will deploy cert-manager because it meets their needs. Not necessarily the needs of the security team.

With eyes on this section’s word count, we’re going to try and wrap this up so we don’t turn this beautiful guide into a sales pitch. We’re also acutely aware that every enterprise will have varying levels of Kubernetes maturity. That said, when you need full visibility of your organisation’s cloud native security posture - make sure you check us out.

Jestack Secure is free to use for your first cluster for as long as you need it, and we won’t spam you with unwanted emails from our marketing team - we’ll leave you to explore the services and see its value for yourself.

Additional resources