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 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.

AIStor 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 supports the following TLS 1.2 and 1.3 cipher suites as supported by Go. Recommended algorithms are marked with an asterisk (*):