Network Encryption (TLS)

MinIO supports Transport Layer Security (TLS) 1.2+ encryption of incoming and outgoing traffic.

SSL is Deprecated

TLS is the successor to Secure Socket Layer (SSL) encryption. SSL is fully deprecated as of June 30th, 2018.

Enabling TLS

Supported Secret Types

MinIO supports three types of secrets in Kubernetes.

opaque

Using private.key and public.crt files.
tls

Using tls.key and tls.crt files.
cert-manager 1.7.x or later

Running on Kubernetes 1.21 or later.

Note

For the best support of tls or cert-manager secrets, upgrade to Operator version 5.0.10 or later.

Multiple Domain-Based TLS Certificates

The MinIO Operator supports attaching user-specified TLS certificates when deploying or modifying the MinIO Tenant.

These custom certificates support Server Name Indication (SNI), where the MinIO server identifies which certificate to use based on the hostname specified by the connecting client. For example, you can generate certificates signed by your organization’s preferred Certificate Authority (CA) and attach those to the MinIO Tenant. Applications which trust that CA can connect to the MinIO Tenant and fully validate the Tenant TLS certificates.

Supported TLS Cipher Suites

MinIO recommends generating ECDSA (e.g. NIST P-256 curve) or EdDSA (e.g. Curve25519) TLS private keys/certificates due to their lower computation requirements compared to RSA.

MinIO supports the following TLS 1.2 and 1.3 cipher suites as supported by Go. The lists mark recommended algorithms with a icon:

TLS 1.3

TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384

TLS 1.2

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

For Kubernetes clusters with a valid TLS Cluster Signing Certificate, the MinIO Kubernetes Operator can automatically generate TLS certificates while deploying or modifying a MinIO Tenant. The TLS certificate generation process is as follows:

The Operator generates a Certificate Signing Request (CSR) associated to the Tenant. The CSR includes the appropriate DNS Subject Alternate Names (SANs) for the Tenant services and pods.

The Operator then waits for CSR approval
The CSR waits pending approval. The Kubernetes TLS API can automatically approve the CSR if properly configured. Otherwise, a cluster administrator must manually approve the CSR before Kubernetes can generate the necessary certificates.
The Operator applies the generated TLS Certificates to each MinIO Pod in the Tenant.

The Kubernetes TLS API uses the Kubernetes cluster Certificate Authority (CA) signature algorithm when generating new TLS certificates. See Supported TLS Cipher Suites for a complete list of MinIO’s supported TLS Cipher Suites and recommended signature algorithms.

By default, Kubernetes places a certificate bundle on each pod at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt. This CA bundle should include the cluster or root CA used to sign the MinIO Tenant TLS certificates. Other applications deployed within the Kubernetes cluster can trust this cluster certificate to connect to a MinIO Tenant using the MinIO service DNS name (e.g. https://minio.minio-tenant-1.svc.cluster-domain.example:443).

Subject Alternative Name Certificates

If you have a custom Subject Alternative Name (SAN) certificate that is not also a wildcard cert, the TLS certificate SAN must apply to the hostname for its parent node. Without a wildcard, the SAN must match exactly to be able to connect to the tenant.

Certificate Management with cert-manager

The MinIO Operator supports using cert-manager as a full replacement for its built-in automatic certificate management or user-driven manual certificate management. For instructions for deploying the MinIO Operator and tenants using cert-manager, refer to the cert-manager page.

Third-Party Certificate Authorities

The MinIO Kubernetes Operator can automatically attach third-party Certificate Authorities when deploying or modifying a MinIO Tenant.

You can add, update, or remove CAs from the tenant at any time. You must restart the MinIO Tenant for the changes to the configured CAs to apply.

The Operator places the specified CAs on each MinIO Server pod such that all pods have a consistent set of trusted CAs.

If the MinIO Server cannot match an incoming client’s TLS certificate issuer against any of the available CAs, the server rejects the connection as invalid.

Self-signed, Internal, Private Certificates, and Public CAs with Intermediate Certificates

If deploying MinIO Tenants with certificates minted by a non-global or non-public Certificate Authority, or if using a global CA that requires the use of intermediate certificates, you must provide those CAs to the Operator to ensure it can trust those certificates.

The Operator may log warnings related to TLS cert validation for Tenants deployed with untrusted certificates.

The following procedure attaches a secret containing the public.crt of the Certificate Authority to the MinIO Operator. You can specify multiple CAs in a single certificate, as long as you maintain the BEGIN and END delimiters as-is.

Create the operator-ca-tls secret

The following creates a Kubernetes secret in the MinIO Operator namespace (minio-operator).
```
kubectl create secret generic operator-ca-tls \
   --from-file=public.crt -n minio-operator
```
The public.crt file must correspond to a valid TLS certificate containing one or more CA definitions.
Restart the Operator

Once created, you must restart the Operator to load the new CAs:
```
kubectl rollout restart deployments.apps/minio-operator -n minio-operator
```