Enable Network Encryption

MinIO AIStor implements Transport Layer Security (TLS) 1.2+ encryption with support for Server Name Indication (SNI) for selecting relevant TLS certificates in response to client requests.

MinIO AIStor supports two types of certificate management:

• Automatic TLS certificate provisioning (default)
• User-provided TLS certificates

When deploying an MinIO AIStor resource, the CRD definition provides a certificates field for controlling certificate generation and behavior. This field is also available in the object store Helm chart.

For Kubernetes clusters with a valid TLS Cluster Signing Certificate, MinIO AIStor by default automatically generates TLS certificates when you deploy or modify an object store using the Kubernetes certificates.k8s.io API. This certificate includes the appropriate DNS Subject Alternate Names (SANs) for the object store Services and Pods.

Kubernetes by default uses the Kubernetes cluster Certificate Authority (CA) to sign and provision certificates. This certificate is typically placed on each Pod at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt such that other applications within the same Kubernetes cluster can create secured connections using Kubernetes DNS.

The Operator also generates its own TLS certificates for secure communication. You can customize this behavior using Operator Environment Variables such as OPERATOR_AUTO_CERT_DISABLED and OPERATOR_CUSTOM_TLS_SECRET_NAME.

The MinIO AIStor CRD definition provides a certificates field for providing user-controlled certificates to the object store.

Create the Secrets as type kubernetes.io/tls in the object store Namespace and specify them when creating the object store resource. The Operator automatically attaches these certificates to the Pods in support of TLS connectivity to hostnames covered by those certificates.

The Operator allows dynamic certificate updates without requiring Pod restarts. AIStor Server RELEASE.2026-02-02T23-40-11Z and later checks the Secrets symlinks to the certificates folder for changes every minute.

When you modify the TLS Secrets referenced by an object store:

1. The Operator detects the Secret change and triggers a reconciliation.
2. The Operator signals the MinIO AIStor process to reload its certificates.
3. MinIO AIStor scans the certificates directory and loads the updated certificates.
4. Changes take effect without restarting Pods.

If certificate loading fails during a reload, MinIO AIStor continues using the previously loaded certificates and logs the error.

After updating certificates, verify that MinIO AIStor is serving the new certificate:

# Get the service endpoint
SERVICE_HOST=$(kubectl get svc -n NAMESPACE OBJECTSTORE-hl -o jsonpath='{.metadata.name}')

# Check the certificate being served
openssl s_client -connect ${SERVICE_HOST}.NAMESPACE.svc:9000 -servername ${SERVICE_HOST}.NAMESPACE.svc </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Replace NAMESPACE with your object store namespace and OBJECTSTORE with your object store name.

The output displays the certificate’s subject and validity dates. Compare these against your expected certificate to confirm the update succeeded.

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

MinIO AIStor in FIPS mode supports only the AES ciphers.