Server Side Encryption with KES

This page enables Server-Side Encryption (SSE) on a Kubernetes MinIO AIStor deployment using the Key Encryption Service (KES) to connect a supported third-party KMS. For instructions on running KES, see the KES docs.

For background on how AIStor encrypts data and the encryption types it supports, see Enable Server-Side Encryption.

Prerequisites

• The MinIO AIStor Kubernetes Operator deployed on your Kubernetes cluster.

• Object store services and pods accessible from your local host, to support management with the AIStor Client (mc).

  For internal hosts, use the service DNS name. For external hosts, specify the hostname of the service exposed by Ingress, Load Balancer, or other Kubernetes network control component.

• An existing KMS installation accessible from your cluster.

  For deployments on the same cluster as your object store, you can use Kubernetes Service names to connect the object store with the KMS service.

  For external deployments, you must make sure the cluster supports communications between Kubernetes services and pods and the external network. This may require configuring or deploying additional Kubernetes network components or enabling access to the public internet.

Refer to the installation instructions for your supported KMS target to deploy KES and connect it to a KMS solution:

• AWS Secrets Manager
• Azure KeyVault
• Entrust KeyControl
• Fortanix SDKMS
• Google Cloud Secret Manager
• HashiCorp Vault
• Thales CipherTrust Manager (formerly Gemalto KeySecure)

Procedure

1. Connect the object store to KES.

   The object store reads its KES settings from environment variables in its configuration secret. Edit that secret with steps 1 through 7 of Server Side Encryption with MinIO KMS. In step 4, add the following KES settings instead of the MinIO KMS settings:

   # The address of the KES service.
   MINIO_KMS_KES_ENDPOINT="https://KES-SERVICE.KES-NAMESPACE.svc.cluster.local:7373"
   
   # The API key from `kes identity new`.
   MINIO_KMS_KES_API_KEY="kes:v1:APIKEYSTRING"
   
   # The default encryption key.
   # Do not change this value after setup.
   MINIO_KMS_KES_KEY_NAME="object-store-default-key"

   If the KES server certificate comes from a private CA, add that CA to objectStore.certificates.trustedCAs in the Helm values. The Operator copies it to every object store pod, and AIStor uses it to verify KES.

   See KES settings for all variables, including mTLS client certificates.

2. Generate a new encryption key.

   If needed, unseal the backing vault instance before you create a new key. See the documentation for your KMS solution.

   Run the mc admin kms key create command against the object store:

   # Replace encrypted-bucket-key with the name of the key you want to use for SSE-KMS
   mc admin kms key create k8s encrypted-bucket-key

3. Enable SSE-KMS for a bucket

   You can use either the console or the AIStor Client to enable bucket-default SSE-KMS with the generated key:

   Console UI`mc`

   1. In the Console UI, create a new bucket. Or, select an existing bucket.

   2. In the left-hand menu, select Encryption, provide the required information, and select Save.

   3. Add a file to the bucket, and confirm the associated encryption metadata.

   Create a new alias for the AIStor Server. You can then run mc encrypt set to enable SSE-KMS encryption for a bucket:

   mc alias set k8s https://minio.minio-tenant-1.svc.cluster-domain.example:443 ROOTUSER ROOTPASSWORD
   
   mc mb k8s/encryptedbucket
   mc encrypt set SSE-KMS encrypted-bucket-key k8s/encryptedbucket

   For clients external to the Kubernetes cluster, specify the hostname of the service exposed by Ingress, Load Balancer, or similar Kubernetes network control component.

   Write a file to the bucket using mc cp or any S3-compatible SDK with a PutObject function. You can then run mc stat on the file to confirm the associated encryption metadata.