Jetstack Cert-manager Latest Version

[Anush Faigley]

Allcert-manager releases are supported at least until the release of a second subsequent version.That means there are always at least two supported versions of cert-manager at any given time,and possibly more if there's also a current Long Term Support version.

You don't have to wait until the next minor release to start using new features; we also aim tocreate regular alpha releases which - while not as thoroughly tested or stable as other releases -should be stable enough to run.

Our support window is four months for each release branch. In the belowdiagram, release-1.2 is an example of a release branch. The supportwindow corresponds to the two latest releases, given that we produce a newfinal release every two months. We offer two types of support:

Technical assistance is offered on a best-effort basis for supportedreleases only. You can request support from the community on KubernetesSlack (in the #cert-manager channel), usingGitHub Discussions or using the cert-manager-devGoogle group.

Breaking changes are changes that intentionally break the cert-managerKubernetes API or the command line flags. We avoid making breaking changeswhere possible, and where they're required we'll give as much notice aspossible.

We aim to be conservative in what we back-port. That applies especially for anything whichcould be a runtime change - that is, a change which might alter behavior for someoneupgrading between patch releases.

We reserve the right to back-port other changes which are unlikely to have a runtime impact, such asdocumentation or tooling changes. An example would be #5209 which updated how we perform a release ofcert-manager but didn't have any realistic chance of having a runtime impact.

In practice, this is largely determined based on what versions of kindare available for testing, and which versions of Kubernetes are provided by major upstream cloud Kubernetes vendorsincluding EKS, GKE, AKS and OpenShift.

The term "release" (or "minor release") refers to one minor version ofcert-manager. For example, 1.2 and 1.3 are two releases. Note that we donot use the prefix v for releases (just "1.2"). This is because releasesare not used as git tags.

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.

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.

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.

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.

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.

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.

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.

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)

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?

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.

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.

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?

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.

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.

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.

"DevSecOps stands for development, security, and operations. It's an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle."

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.

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.

3a8082e126