This post will explore the new features in the recently released cert-manager v0.15, as well as give an overview of our plans for the future of the project. Jump to the bottom for more information on how to get involved and start contributing!
The cert-manager project has come leaps and bounds since its beginnings almost three years ago. Initially started to expand on the success of its predecessor, kube-lego, the project is now used by companies all across the world and in all sorts of industries, including government departments, large financial institutions, car manufacturers and retail stores!
As the Kubernetes extensions/operators ecosystem has evolved, we ourselves have adapted to take advantage of new and important features such as API versioning in the upstream project. This is now possible through the great work of those in #sig-api-machinery, and means we can finally push our project towards a stable ‘1.0’ release in the coming months!
What’s happened recently?
Whilst we say v0.15 here, some of these features and events happened before the v0.15 release. However, we wanted to be sure to call them out as they are all significant milestones in and of themselves 😀.
5,000+ stars, 200+ contributors!
In January we hit a total of 200 contributors according to our GitHub metrics. The reality is we have far more than this, as contributions come in the form of opening issues, discussing use cases and helping other community members in our ever-growing Slack channel.
At the same time, we hit 5,000 stars on GitHub - this is a massive achievement for the team, and serves to demonstrate just how widely cert-manager is used.
Whilst we try not to measure ourselves solely on GitHub metrics, it is an achievement everyone should be proud of. This success was not born out of any individual or one company’s efforts, rather the combined work of an entire ecosystem collaborating and working together to improve security and best practices together.
External Issuer types
Since the dawn of the project, one of our major goals has been to allow any certificate authority to integrate with the cert-manager ecosystem and begin benefiting from our automation around Ingress resources (providing a ‘one-click’ way to secure HTTP services), the CSI driver, auto-renewing Certificate resources and many more solutions still to come.
In the v0.11 release, we added support for External issuer types.
This feature enables anyone to plug in support for any kind of CA, be that public, private or internal.
So far we’ve seen Smallstep publish their step-issuer, which enables retrieving certificates from your Smallstep CA.
cert-manager-csi
Container Storage Interface (CSI) was introduced in Kubernetes to allow storage vendors to expose their own storage solutions and integrate them into Kubernetes.
There are also provisions in the specification to allow for ‘inline’ volumes, which are short-lived ephemeral storage volumes which are managed by a CSI driver.
The cert-manager-csi
project implements a CSI driver that interacts with cert-manager to allow you to request certificates on a per-pod basis, ensuring they are kept up to date and renewed at all times.
We see this as a great tool for those that may be looking to migrate legacy applications over to Kubernetes, or those who have stricter per-pod identity requirements as part of their infrastructure.
Kubectl CLI plugin
Kubectl is the command line tool everyone that interacts with a Kubernetes cluster will be familiar with.
In recent Kubernetes releases, kubectl was extended to support ‘plugins’ which can be used to make additional commands available.
The v0.15
release includes a kubectl plugin which can be used to perform advanced operations with your cert-manager installation.
Initially, the plugin supports two commands:
convert
- to allow converting resources stored in GitOps-like repos between cert-manager API versions.renew
- to trigger a manual renewal of a certificate ahead of its expiry date.
The renew
feature is the culmination of a lot of work and collaboration going on in order to improve our ‘Certificate’ controller to make it easier to extend and interact with. Expect more neat features here soon!
Kubernetes project domains secured with cert-manager!
The Kubernetes project has been working to move project related operations and services over into community owned infrastructure as part of #wg-k8s-infra. This has involved, among many other things, setting up the various k8s.io websites on new Kubernetes clusters hosted on Google Cloud.
As part of this transition, a solution for securing these websites with HTTPS was required. The decision was made to deploy and run cert-manager in these clusters, in order to fetch publicly trusted TLS certificates from Let’s Encrypt.
It’s a huge honor, and sign of the project’s position in the community, that our project is being used to secure the very community sites that brought about cert-manager’s existence 🎉.
Expanding our support for OpenShift & the Red Hat ecosystem
Red Hat’s OpenShift is a popular platform amongst enterprises who are looking to adopt Kubernetes.
In order to better serve these users, we’ve been working hard to make cert-manager available via the OpenShift embedded OperatorHub, a place for users to install and manage the software running in their clusters.
Starting with v0.15
, cert-manager is now available for one-click installation through the OpenShift dashboard. This will make it far easier to install, manage and upgrade cert-manager installations in enterprise environments!
What’s next?
As you can see, we’ve been up to a lot! But there’s still plenty left to do, and new requirements arise every day.
Here’s a preview of what’s on our minds for the coming few months, and what we’re aiming to achieve:
Tooling and integrations with other projects
Whilst a lot of users consume cert-manager certificates via Kubernetes Ingress resources, there is a growing need to consume certificates in a variety of different ways, either directly within pods or even through storing in other external systems.
We want to better cater for these kinds of use-cases, and have made a start on it with the new cert-manager-csi tool, a CSI driver for Kubernetes that allows you to transparently ‘mount’ certificate data into your pods and keep it up to date.
We will be looking into ways we can expose certificate retrieval capabilities into the new CLI plugin, as well as how we can better serve service mesh products like Istio & Linkerd with identities obtained from cert-manager.
Moving our API to v1beta1
cert-manager was one of the first operators to be developed, and as a result, we initially had far fewer tools at our disposal to allow us to manage and maintain our CRD’s API in a stable manner.
With the addition of Kubernetes conversion webhooks, we’re now able to incrementally release new versions of our whilst allowing a seamless upgrade experience for users, in a similar manner to Kubernetes' own deprecation policy.
Given the widespread usage of our APIs already, it’s essential we start to provide promises and guarantees around the stability of our API.
In v0.16
we will be introducing a new API version, v1beta1
. This follows on from v1alpha3
which was quietly rolled into the v0.14
release in order to test our conversion capabilities.
This is a major step in our progress towards 1.0, in which the v1
API version will also finally be published!
v1.0
release
It’s been a long time coming, and it’s very much top of mind - we are aiming to release v1.0
of the cert-manager project, alongside our v1
API, in the coming months. The first step will of course be to v1beta1
, but given the size of our user base and the critical nature of the software, we do not intend to make significant changes to our API any longer.
We have a [milestone on GitHub] to track features we deem required for v1.0
, however we’re trying our utmost to find ways to implement new features in a backwards compatible way after we have release v1.0
, so we do not delay the milestone any longer.
Getting involved
Thanks for reading this far! If you want to get involved in the project, we have various meetings and communication channels and always welcome new participants, in whatever capacity.
First, sign up for the mailing list which we use to send out calendar invites. Once you have joined, you’ll receive invites to our bi-weekly development meeting (held on Wednesday’s at 5pm UTC).
The #cert-manager and #cert-manager-dev channels on the Kubernetes Slack is also a great place to start and get chatting about ideas or questions you have. Please drop by and say hello!
We also host daily stand ups at 10.30am UK time where we discuss what’s being worked on for the day and go over any recent/new issues. You’ll receive invites to this after joining the above Google group too.
Thanks!
Once again, a huge thank you to all that have been involved and helped get cert-manager to where it is today. We’re really looking forward to what’s up next, and look forward to working with you in the community!