Kubernetes Container TLS

There’s a wide range of use cases for certificates inside containers, depending on what you're running. Since you can run any application/service inside a container, asking why a container might need a certificate is roughly equivalent to asking why an application/service might need a certificate. Here are a few examples.

There are two primary patterns used to get certificates to containers

1. A kubernetes.io/tls Secret

A kubernetes.io/tls Secret is a Kubernetes object type designed to hold an X.509 certificate (tls.crt) and private key (tls.key) for use with TLS. Like other Secrets, TLS Secrets can be mounted into pods, read/written by clients with appropriate access, and can be referenced by some other resources.

2. Deliver the certificate directly to the container.

There's a few ways to deliver a certificate directly to a container in Kubernetes. We created Autocert to make it easy to use mutual TLS to improve security within a cluster and to secure communication into, out of, and between Kubernetes clusters.

Autocert is a kubernetes add-on that automatically injects TLS/HTTPS certificates into your containers. To get a certificate, simply annotate your pods with a name. An X.509 (TLS/HTTPS) certificate is automatically created and mounted at /var/run/autocert.step.sm/ along with a corresponding private key and root certificate (everything you need for mTLS).

When you want to get a certificate to a container in Kubernetes, you must first ask:

Do you trust the backing datastore you're using for Kubernetes (often this is etcd)?

This datastore is used for Kubernetes TLS Secrets and is where the certificate and private keys are stored. Depending on how your datastore is configured, the data may or may not be encrypted.

Here are two common answers to this question and what we recommend: