autocert: automatic mTLS certificates for Kubernetes pods

The problem Autocert solves: somebody has to run the CA

Autocert is described as a Kubernetes add-on that automatically injects TLS/HTTPS certificates into your containers so they can communicate with each other securely. The mechanism for opting in is deliberately small: annotate a pod with a name and an X.509 certificate is created and mounted, together with its private key and the root certificate.

The README is clear that the hard part of TLS is not the encryption. You already use TLS, and your existing tools and standard libraries provide most of what you need. The problem is the certificate authority. Building and operating a CA, issuing certificates from it, and making sure they are renewed before they expire is the part that is tricky, and Autocert takes that on.

The motivation section is about mutual TLS. The README argues that mTLS gives you authenticated encryption, an identity dialtone and end to end encryption for workloads, and that it makes workloads identity aware, which improves observability and enables granular access control. It also makes it possible to communicate securely with workloads running anywhere, not only inside Kubernetes.

The comparison the README draws is with VPNs and software defined networks. Those solve the identity problem by putting workloads on an overlay, and they come with their own operational weight. Autocert's argument is that mTLS over ordinary networking is comparatively easy to deploy and scale, because the transport is already there.

How the pieces fit: controller, bootstrapper, renewer and an init job

The repository layout shows the moving parts. There is a controller directory, a bootstrapper directory and a renewer directory, plus an init directory holding init/autocert.sh, an install directory and an examples directory with a hello-mtls example.

Autocert runs step-ca internally to generate keys and issue certificates. That step-ca instance is the Certificate Authority for the cluster, and it can also be the one you point external clients at, since the README says that because autocert is built on step-ca you can extend access to developers, endpoints and workloads running outside your cluster.

Two properties of that design are worth naming because they answer the obvious objections. The feature list states that private keys are never transmitted across the network and are not stored in etcd. Certificates are short lived, with fully automated enrollment and renewal. And the installation is namespaced into the step namespace so it is easy to lock down your CA.

The certificates are described as RFC5280 and CA/Browser Forum compliant, which is the property that lets them work for TLS rather than only for internal key agreement.

The Go module shows how the project is built. The module path is github.com/smallstep/autocert, the Go directive is 1.25.0, and the direct dependencies include github.com/smallstep/certificates v0.30.2 for the CA, go.step.sm/crypto v0.77.2, google.golang.org/grpc v1.79.3, github.com/sirupsen/logrus, sigs.k8s.io/yaml and the Kubernetes libraries k8s.io/api and k8s.io/apimachinery, both pinned to v0.36.0-alpha.2.

Installing it: a one-shot init container or the Helm chart

The prerequisites are short. You need kubectl and a cluster running Kubernetes with admission webhooks enabled, and the README shows the version check it expects.

$ kubectl version
Client Version: v1.26.1
Kustomize Version: v4.5.7
Server Version: v1.25.3
$ kubectl api-versions | grep "admissionregistration.k8s.io/v1"
admissionregistration.k8s.io/v1

The admission webhook requirement is the real constraint. Autocert works by mutating pods as they are admitted, so a cluster that does not run admission webhooks cannot use it.

The quick install runs a single job that creates the namespace and the CA for you.

kubectl run autocert-init -it --rm --image cr.smallstep.com/smallstep/autocert-init --restart Never

The README suggests reading init/autocert.sh before running it, and points at INSTALL.md for a manual install if you prefer to do it yourself.

The Helm path is the alternative for anyone who wants the release to be managed like the rest of their cluster configuration.

helm repo add smallstep https://smallstep.github.io/helm-charts/
helm repo update
helm install smallstep/autocert

The chart's configuration options are listed at the Helm hub page for smallstep/autocert, and the release is versioned through the GitHub releases page.

Enabling it: a namespace label and a pod annotation

Using Autocert takes two steps, and the README presents them in that order.

First, opt a namespace in by labelling it autocert.step.sm=enabled.

kubectl label namespace default autocert.step.sm=enabled

To see which namespaces are opted in, list the label across namespaces.

$ kubectl get namespace -L autocert.step.sm
NAME          STATUS   AGE   AUTOCERT.STEP.SM
default       Active   

Second, annotate individual pods with autocert.step.sm/name and the name you want in the certificate. That annotation is what triggers issuance for that workload.

The two level design is the part that makes sense in a real cluster. The namespace label is the platform team's switch, deciding where the CA is allowed to act, and the pod annotation is the application team's switch, deciding which workloads get an identity. A service mesh style opt in per namespace, with per workload naming on top, means a workload that needs a certificate but has no certificate does not silently fall back to plaintext.

The mount point is /var/run/autocert.step.sm/, and it holds the certificate, the corresponding private key and the root certificate, so a container has everything it needs for mTLS without a second lookup.

Autocert versus step-issuer: mounted files or Kubernetes Secrets

The README names an alternative directly. Smallstep also publishes step-issuer, a cert-manager Certificate Issuer that works with either a step-ca server or the hosted Certificate Manager CA.

The difference in approach is the delivery mechanism. Autocert mounts certificates and keys directly into pods, through an admission webhook that mutates the pod specification at admission time. step-issuer makes them available as Secrets, which the workload then reads through the normal Secret volume mechanism. Autocert is a Kubernetes add-on in the full sense, with a controller and a mutating webhook; step-issuer is a cert-manager issuer, so it inherits cert-manager's certificate lifecycle machinery instead of running its own controller.

That difference matters in concrete situations. If your organisation already runs cert-manager with an issuer per cluster, adding a second admission based controller is redundant, and step-issuer fits the workflow you already have. If you do not run cert-manager and you want certificates to appear without any application configuration at all, the webhook approach means a container finds its key already on disk at the mount path and needs nothing from its own configuration.

There is also a difference in what gets mounted. Autocert gives the container the certificate, the private key and the root certificate together, which is exactly the set a workload needs to act as an mTLS client and to verify its peers. A Secret based flow can carry the same files, but assembling that bundle is a step the workload or the chart has to do.

Limits worth knowing before you install a CA in your cluster

The first limit is the alpha dependency. The go.mod file pins k8s.io/api and k8s.io/apimachinery to v0.36.0-alpha.2. A library built against an alpha version of the Kubernetes API is a meaningful dependency decision, and it is the sort of thing that changes when the upstream library moves.

The second is the CA itself. Autocert puts a private CA inside your cluster and gives it the ability to issue identities for workloads. The README addresses the obvious concern by pointing at namespaced installation into the step namespace so it is easy to lock down your CA, and by stating that private keys are never transmitted across the network and are not stored in etcd. The repository also carries SECURITY.md, which is where a security policy lives, and a RUNBOOK.md for operational procedures. Both files are worth reading before you let a CA issue for production workloads, and the README does not describe the contents of either.

The third limit is scope. The certificates are for workloads talking to workloads, internally and to clients outside the cluster, all of whom must trust your CA. Autocert is not described as a way to obtain publicly trusted certificates for browsers, and it is not an ingress controller. If the requirement is public web TLS on an internet facing service, this tool does not address it.

The fourth is operational surface. The Makefile shows the project expects golangci-lint, govulncheck and gotestsum in a developer environment, and the build embeds a version and build time into the binary and is cut with goreleaser, so shipping a fork or a patch means maintaining that release path yourself.

Activity, licence and the shape of the project

The repository is not archived, and the last push was on 2026-10-14. The release list shows v0.20.6 on 2026-03-23, v0.20.5 on 2026-03-19 and the release candidate v0.20.5-rc2 on the same day, so the project tags small patch releases on a quick cadence and uses release candidates before a final tag.

The licence is Apache-2.0, with the LICENSE file at the repository root. That is a permissive licence with the usual obligations around preserving notices, and it is the same terms the Kubernetes ecosystem generally uses for infrastructure components.

The project is written in Go, with the module at github.com/smallstep/autocert and a Go directive of 1.25.0. The Makefile builds a binary named autocert from the controller package, with CGO_ENABLED=0 set, which means the resulting binary is statically linked and easy to run in a distroless container.

For evaluation, the useful documents are the ones at the top level. README.md covers the concept and the quick start, INSTALL.md covers manual installation, RUNBOOK.md covers operations, SECURITY.md covers the security policy, and the examples directory holds a hello-mtls sample with its own README that the main README links to for the mutual TLS walkthrough. AGENTS.md and the .claude directory also sit at the top level, which suggests the project has been set up for automated coding assistants.

Editorial conclusion

Autocert fits teams that already run Kubernetes with admission webhooks enabled and want mutual TLS between services, including workloads outside the cluster, without building a CA and a renewal process themselves. Do not reach for it for public internet certificates, for clusters where admission webhooks are unavailable, or for environments that want keys delivered as Kubernetes Secrets rather than as mounted files. Before installing, confirm the cluster satisfies the kubectl and admission webhook prerequisites, decide whether the internal step-ca or the hosted Certificate Manager issues the certificates, and read RUNBOOK.md and SECURITY.md, since the operation of a private CA inside your cluster deserves a plan before the first rollout.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. smallstep/autocert on GitHub