Enable Network Encryption

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.

AIStor supports two types of certificate management:

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

When deploying an AIStor Object Store 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, 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 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 AIStor process to reload its certificates.
3. AIStor scans the certificates directory and loads the updated certificates.
4. Changes take effect without restarting Pods.

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

After updating certificates, verify that 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.

AIStor in FIPS mode supports only the AES ciphers.