Server Side Encryption Settings
AIStor Server connects to a key manager to perform Server-Side Encryption (SSE). This page groups the environment variables by the key manager they configure:
- MinIO KMS — the recommended key manager for new deployments.
- MinIO Key Encryption Service (KES) — the legacy path to a supported third-party KMS.
- Static key files — a single built-in key, intended for testing only.
Define exactly one of these groups. Defining variables from more than one group causes the server to fail on startup.
The common settings for auto-encryption and key replication apply regardless of which key manager you configure.
Define any one set of these environment variables in the host system prior to starting or restarting the MinIO AIStor process. Refer to your operating system’s documentation for how to define an environment variable.
MinIO KMS
Define the following variables to use MinIO KMS to manage keys. MinIO KMS is the recommended key manager for new deployments.
The common settings for auto-encryption and key replication apply when using MinIO KMS.
MINIO_KMS_SERVER
The endpoint(s) for the MinIO KMS process to use for supporting SSE-S3 and AIStor Server backend encryption operations.
Separate multiple endpoints with a comma (,).
AIStor server load-balances and fails over across the MinKMS servers natively.
MINIO_KMS_ENCLAVE
The MinIO KMS Enclave where the key and identity exist.
MINIO_KMS_SSE_KEY
The default key to use for SSE-S3 encryption when a call does not specify a key identity.
MINIO_KMS_API_KEY
The credential used to authenticate with the MinIO KMS service.
Create the API key with an identity that has permission to access the MINIO_KMS_ENCLAVE.
See also MINIO_KMS_REPLICATE_KEYID for behavior when replicating encrypted objects across sites.
MinIO Key Encryption Service (KES)
Define the following variables to use the Key Encryption Service (KES) to connect to a supported 3rd party key management service provider. The common settings for auto-encryption and key replication also apply when using KES.
MINIO_KMS_KES_ENDPOINT
The endpoint(s) for the MinIO Key Encryption Service (KES) process to use for supporting SSE-S3 and MinIO backend encryption operations.
Separate multiple KES endpoints with a comma (,).
MINIO_KMS_KES_KEY_NAME
The name of an external key on the Key Management system (KMS) configured on the KES server and used for encryption and decryption. MinIO AIStor uses this key for the following:
- Encrypting backend data.
- The default encryption key for Server-Side Encryption with SSE-KMS.
- The encryption key for Server-Side Encryption with SSE-S3.
See Supported Encryption Types.
Enabling SSE on a MinIO AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key.
MinIO AIStor requires access to KES and the external KMS to decrypt the backend and start normally.
The KMS must maintain and provide access to the MINIO_KMS_KES_KEY_NAME.
You cannot disable KES or “undo” the encryption configuration at a later point.
MINIO_KMS_KES_API_KEY
Preferred method for authenticating with the encryption service using the KES API key obtained from the kes identity new command.
This environment variable is mutually exclusive with the MINIO_KMS_KES_KEY_FILE and MINIO_KMS_KES_CERT_FILE environment variables.
MINIO_KMS_KES_KEY_FILE
The private key associated to the the MINIO_KMS_KES_CERT_FILE x.509 certificate to use when authenticating to the KES server.
The KES server requires clients to present their certificate for performing mutual TLS (mTLS).
See the KES wiki for more complete documentation on KES access control.
You must also set the MINIO_KMS_KES_CERT_FILE.
This variable is mutually exclusive with MINIO_KMS_KES_API_KEY.
MINIO_KMS_KES_CERT_FILE
The x.509 certificate to present to the KES server. The KES server requires clients to present their certificate for performing mutual TLS (mTLS).
The KES server computes an identity from the certificate and compares it to its configured policies.
The KES server grants the minio server access to only those operations explicitly granted by the policy.
See the KES wiki for more complete documentation on KES access control.
You must also set the MINIO_KMS_KES_KEY_FILE.
This variable is mutually exclusive with MINIO_KMS_KES_API_KEY.
MINIO_KMS_KES_CAPATH
Optional
Allows validation of the KES server certificate issued by a self-signed or third-party certificate authority (CA). Specify the path to the CA certificate for your KES deployment.
This variable is not required if you use a public certificate authority.
MINIO_KMS_KES_KEY_PASSWORD
Optional
The password used to encrypt and decrypt the TLS private key, if used.
Static key files
Provide a single static key, or a file containing one, to use for encryption instead of a dedicated key manager. A static key implements only a subset of the KMS API and does not support creating additional keys or key rotation.
MINIO_KMS_SECRET_KEY
The base64 form of the static KMS key in the form <key-name>:<base64-32byte-key>.
Implements a subset of KMS APIs.
Creating new master keys with mc admin kms key create is not supported when using the static key.
Use MinIO KMS (MinKMS) or KES to create keys.
MINIO_KMS_SECRET_KEY_FILE
Path to the file to read the static KMS key from.
Common settings
These settings apply to any key manager. The examples use MinIO KMS, the recommended key manager.
MINIO_KMS_AUTO_ENCRYPTION
Optional
When a key manager is configured, AIStor Server automatically encrypts all objects using SSE-KMS.
Set this environment variable to off to disable automatic encryption.
If set to off, you must manually enable encryption on a per-bucket basis.
Defaults to on.
MINIO_KMS_REPLICATE_KEYID
Controls whether AIStor Server includes the encryption key ID in an object’s metadata when replicating that object to a peer site or bucket.
Defaults to on, which replicates the key ID with the object.
Set to off to omit the key ID during replication.
When an object arrives without a key ID, the destination site or bucket applies its own encryption configuration.
Set this variable to off when peer sites use independent KMS deployments with no shared keys.
Otherwise, replication can fail when a key that exists on one site does not exist on another.