What is the history of cert-manager?
Who can better explain the ins and outs of cert-manager than the people who made it all happen? This is your ultimate guide for all things cert-manager from the experts who created it. And to kick things off, let’s start with a little history lesson.
Back in 2017, when cert-manager was first released as an open-source project, we always suspected we were onto something big. Fast-forward a few years and cert-manager has surpassed a billion downloads, has collected more than 10,000 GitHub stars, and is an officially adopted project within the CNCF.
We couldn’t be prouder that cert-manager has become the go-to solution for issuing and renewing X.509 certificates from within Kubernetes clusters. When you consider the need to secure and manage the overall speed and scope of Kubernetes and the OpenShift adoption, the popularity of cert-manager has only just begun.
Cloud native technologies are now the de facto standard for new applications, and with Kubernetes the undisputed leader for orchestrating containerized workloads, there are a staggering 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. This is your strategic overview of how cert-manager can allow you to secure cloud native workloads, now and well into the future.
What are x.509 certificates and machine identities?
Before diving into the key benefits of cert-manager, let’s start with some context around 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. 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 organizations known as Certificate Authorities (CAs). 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. Venafi Firefly is a lightweight, lightning-fast machine identity issuer that can deploy all types of machine identities across multiple environments!
Check out this quick video for more content on the role X.509 certificates 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 organization's own data center. 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 organizations 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 utilization - and although organizations would still need to run various operating systems (OS) 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 OS 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 OS 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.
What is Kubernetes?
Kubernetes is the world’s most popular orchestration platform for containerized workloads - with 96% of CNCF members already using it in production as of 2022. In short, Kubernetes is a centralized management platform that helps ensure that containers are running to their required spec. This helps you scale your applications to keep in line with demand.
What are Kubernetes clusters?
Kubernetes clusters have one or more nodes for running containerized applications. There are various ways you can setup your Kubernetes clusters to manage containerized workloads, however, here are three common examples:
While 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 faster rate than ever before, causing developers and security teams all kinds of potential challenges. According to the most recent Red Hat State of Kubernetes Report, more than 90% of organizations experienced a Kubernetes-related security incident, with workload misconfigurations cited as the most common cause.
What is cert-manager?
At its core, 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. Once installed, cert-manager can issue and renew certificates for all the machine identities contained within a cluster, no matter how short their lifespans become.
It's easy to see the role cert-manager can play for your organization. With the use of cloud native technologies and Kubernetes only heading in one direction, the management and protection of cloud native machine identities is increasingly complex. But it doesn’t have to be!
Organizations that use cert-manager reduce the likelihood of certificate-based outages and secure their workloads by verifying all the machine identities that are contained within a Kubernetes cluster. Without cert-manager, manually finding and configuring TLS certificates will become ridiculously burdensome, and time-consuming. Thankfully, cert-manager removes this burden for developers, which is why they love using cert-manager.
How does cert-manager work?
To quote cert-manager directly, “cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.” In other words, 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 Certificate Authority, which generates signed certificates as requested. But cert-manager will specify the type of certificate that is needed, how long it should be valid for, renewal terms, and the required issuer. Once it’s been issued, the certificate will be stored as a Kubernetes Secret.
What cloud service providers (CSPs) are compatible with cert-manager?
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
How to get started with cert-manager?
The cert-manager docs site is the best go-to resource for all things technical. Check out these helpful guides to get you started:
What are some uses cases of cert-manager?
cert-manager has received some accolades in recent years. At the start of 2021, cert-manager was being considered an essential general solution for secrets management within the CNCF End User Technology Report. By the end of the year, it was included in the ThoughtWorks Technology Radar for the first time! But what are some of the more practical applications of cert-manager? Why is it being downloaded over a million times each day?
Let's take a closer look at the different ways cert-manager is being deployed to secure cloud native machine identities.
Securing ingress traffic
One of the most widespread uses of cert-manager is to secure incoming traffic to your Kubernetes clusters with TLS encryption. It just makes sense. You wouldn’t give a stranger the keys to your house - so why would organizations running highly distributed infrastructure give unfiltered access to public-facing workloads? They shouldn’t.
By verifying the machine identities of incoming traffic and adopting one of the core principles of Zero Trust (never trust, always verify), organizations will ensure that their public-facing web applications are locked down and tamper-resistant.
mTLS protection
Developers often build internal workloads that aren't necessarily exposed to ingress traffic but could still 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 traffic within clusters.
An mTLS type deployment for mutually authenticated communication would typically use cert-manager as the conduit to issue and renew private certificates. Whether through HashiCorp Vault, ACME, or Venafi Firefly, there are several ways organizations can utilize cert-manager to extend the underlying principles of Zero Trust to include internal workloads.
Managing workloads in a service mesh
A service mesh is a networking technology that allows secure connections between the increasingly expanding number of end points within a cloud native architecture. Often seen as an extension of mTLS, cert-manager can be used to issue and renew certificates within service mesh zones.
A service mesh will only allow access to services within a microservice architecture that has explicit authorization 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, cert-manager acts as a control plane that can be used within service mesh environments to enforce security policies for mesh workload encryption and automated protection.
Blueprint for certificate management success
Cloud native technologies offer reduced operational expenditure and speed-to-market gains, but the cloud also represents a chance to act on the lessons learned from the world of on-premises. As such, many organizations 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 centralized and fully automated approach to certificate management across cloud native infrastructures.
Does cert-manager allow for Zero Trust?
As seen by the use cases described above, cert-manager is a certificate management tool that allows an organization to enact the founding principles of Zero Trust. To support the above-mentioned use cases, organizations can use cert-manager to secure the machine identities of east-to-west traffic as well as ingress.
How does cert-manager enable DevSecOps?
We strongly believe that cert-manager can help developers deploy best-in-class certificate management processes without slowing them down. With this in mind, let's view DevSecOps as the mission to bring security teams and developers closer together. Through this lens, cert-manager can serve as the means to push pre-approved certificates to cloud native workloads.
Of course, there will be a myriad of other issues that need to be tackled at the same time, including culture, visibility, versioning etc. Even so, cert-manager can provide organizations the means to scale a tried-and-trusted solution type (PKI) to cloud native environments.
What kind of scale and visibility does cert-manager offer?
It’s incredible how in such a short time, cert-manager has 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.
But as cloud native environments scale, more needs to be done to enforce consistent usage across the enterprise. With the typical enterprise juggling over 450 applications, we have lost count of the number of times we’ve seen inconsistent versions of cert-manager running in production, or seen certificates issued within Kubernetes clusters that do not adhere to security team best practices.
To combat this, we have created a central Venafi Control Plane that automates certificate management for all types of machine identities across all environments and teams. It 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.
Not only does the Venafi Control Plane allow for consistent and centralized governance of security policy, but it also ensures network-wide visibility and unprecedented reliability of service. Through this central control plane, you can easily utilize Venafi TLS Protect for Kubernetes to enforce policies across Kubernetes workloads enterprise-wide.
We typically 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 standardized tooling in place to keep pace with automation, developers will be ones to make the tooling technology choices. This means they will likely deploy cert-manager because it meets their needs, but not necessarily the full needs of the security team.
We’re acutely aware that every enterprise will have varying levels of Kubernetes maturity. To provide full visibility of your organization's cloud security posture, be sure to take advantage of the TLS Protect for Kubernetes product solution! Connect your first cluster for free and get a first-hand look at your overall machine identity security.
TLS Protect for Kubernetes will give you instant observability into how your Kubernetes clusters are using certificates issued by cert-manager. It is an essential solution to help security teams identify and remediate certificate misconfigurations, which are now very common in Kubernetes clusters.