Network Encryption on Kubernetes

For an overview of network encryption and how to enable TLS with other topologies, see Network Encryption. This page explains how to manage certificates on Kubernetes.

For Kubernetes clusters with a valid TLS Cluster Signing Certificate, the AIStor Operator can automatically generate TLS certificates when you deploy or modify an object store. Here’s how it works:

• The Operator generates a Certificate Signing Request (CSR) for the object store. The CSR includes the appropriate DNS Subject Alternate Names (SANs) for the object store services and pods.

• The CSR waits for approval. The Kubernetes TLS API can automatically approve a properly configured CSR. 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 AIStor pod in the object store.

The Kubernetes TLS API uses the Kubernetes cluster Certificate Authority (CA) signature algorithm to generate new TLS certificates.

By default, Kubernetes places a certificate bundle on each pod at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt. This bundle should include the cluster or root CA used to sign the AIStor TLS certificates. Other applications deployed on the Kubernetes cluster can trust this cluster certificate to connect to an object store with the AIStor service DNS name (for example,https://aistore-object-store-1.svc.cluster-domain.example:443).

The AIStor Operator supports cert-manager as a full replacement for either its automatic certificate management or manual certificate management.

AIStor supports three types of secrets in Kubernetes.

• opaque: with private.key and public.crt files.

• tls: with tls.key and tls.crt files. Best with Operator version 5.0.10 or later.

• cert-manager 1.7.x or later, on Kubernetes 1.21 or later. Best with Operator version 5.0.10 or later.

The Operator supports user-specified TLS certificates you deploy or modify an object store.

Custom certificates support Server Name Indication(SNI), where AIStor identifies the certificate to attach based on the hostname specified by the connecting client. For example, you can generate certificates signed by your organization’s preferred CA and attach them to the object store. Applications that trust the CA can connect to the object store and validate the certificate.

The Operator can automatically attach third-party CAs when you deploy or modify an object store.

You can add, update, or remove CAs at any time. You must restart the object store for the changes to the configured CAs to apply.

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

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

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

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

Here’s how to attach a secret that contains the public.crt of the CA to the AIStor Operator. You can specify multiple CAs in a single certificate with the BEGIN and END delimiters as-is.

1. Create the operator-ca-tls secret (here in the Operator namespace):

   kubectl create secret generic operator-ca-tls \
      --from-file=public.crt -n aistor-operator
   

   The public.crt file must correspond to a valid TLS certificate containing one or more CA definitions.

2. Restart the Operator:

   kubectl rollout restart deployments.apps/aistor-operator -n aistor-operator