Cert-Manager Project update: Beyond 2026

What is cert-manager?

Cert-manager is a group of people interested in X509 stuff. This group of people creates controllers, push the code to GitHub so that the community can use certificates in Kubernetes.

Cert-manager is graduated CNCF project.

It doesn’t matter what resource you use (pod, svc, ingress), cert-manager can issues a certificate for it, using a variety of CA’s like Let’s Encrypt.

Cert-manager also contains the trust-manager project, which is a tool to manage trust stores in Kubernetes. It puts certs in configmaps or secrets so that you can mount them in your workloads.

Governance

One of the focusses of the last couple weeks is Governance. Cert-manager complies with the CNCF’s governance model.

There’s also a new maintainer, proving the health of the project. This new member is a good step for diversity, since up until now most of the maintainers are from Jetstack.

One of the questions they get all the time “why isn’t cert-manager part of Kubernetes?”. The maintainers do not disagree, but the fact that they’re complying with governance requirements and the new maintainer, prove that the project doesn’t need to be in-tree to be healthy.

Latest releases

Some new features:

  • ListenerSet support for Gateway API
  • Helm chart now supports easier configuration of custom registries

ListenerSet

Ingress-nginx is now archived. A lot of the noise around this means that people are looking into replacing their ingress controller. This search is leading them to Gateway API, which is the future of ingress in Kubernetes.

Cert-manager has a part in this.

Due to the wide adoption of cert-manager, cert-manager needs to support Gateway API in order to not hinder migration to the next-gen API.

The maintainers stress that moving to Gateway API is optional, and Ingress is not going anywhere. Both will be supported. But Gateway API is the future and it makes your life easier.

One major issue that was found in the Gateway API spec, is that the TLS config is on the Gateway. Meaning that end-users need to contact Gateway admins to get TLS certs for their workloads. Now, using ListenerSet, end-users can manage TLS config without having to update the Gatway resource. Mor improvements are coming, since there’s quirks, but it’s usable.

Top-tier security

Since cert-manager deals with certificates, security is a top priority. The team has a bunch of measures in place to ensure the project stays secure.

There’s two attack vectors they encounter the most:

  • Supply chain attacks: a hot issue in GitHub projects
    • They reduce their amount of dependencies
    • Avoid unmaintained and unnecessary dependencies
    • Auto dependency updates using Renovate
  • Direct attacks
    • Code scanning/linting
    • Regular security audits
    • Governance model
    • Automated and verifiable releases

Supply chain attacks

By protecting the binaries and source code they use, they try to avoid supply chain attacks. Using a trust-on-first-download model, they verify source code added to the project. This includes GitHub actions and OCI images.

By automating updates of their tooling and dependencies, they can sometimes fix a CVE before scanners ever report it in the tooling.

Direct attacks

Using linting with strict rules, they can prevent malicious code from being merged into main. There’s a couple tools:

  • golangci-lint
  • govulncheck
  • helm-tool-linting (self-built)
  • boilersuite
  • kubeapi linter (KAL)

They also sign images for releases, which can be verified by users.

Combined with the governance model and regular security audits, they can continuously harden cert-manager so it is safe to use.

Future work

  • ACME issuer to be Async
  • Adding image digests to Helm charts
  • Fully migrate cert-manager to Server Side Apply
  • Renewal window support (new feature, lets you specify when certs should be renewed like during office hours)
  • ACME ARI support