Skip to content

This is the multi-page printable view of this section. .

Return to the regular view of this page.

Data Encryption (SSE)

MinIO Server-Side Encryption (SSE) protects objects as part of write operations, allowing clients to take advantage of server processing power to secure objects at the storage layer (encryption-at-rest). SSE also provides key functionality to regulatory and compliance requirements around secure locking and erasure.

MinIO SSE uses the PGSTY KES and an external Key Management Service (KMS) for performing secured cryptographic operations at scale. MinIO also supports client-managed key management, where the application takes full responsibility for creating and managing encryption keys for use with MinIO SSE.

The maintained integration is SILO + PGSTY KES + OpenBao KV v2. Other inherited KES backends require separate validation. The following links describe those integrations:

MinIO SSE requires enabling Network Encryption (TLS).

Supported Encryption Types

SILO implements the S3 encryption request interfaces described in AWS Server-Side Encryption and supports the following encryption strategies:

MinIO supports enabling automatic SSE-KMS encryption of all objects written to a bucket using a specific External Key (EK) stored on the external KMS. Clients can override the bucket-default EK by specifying an explicit key as part of the write operation.

For buckets without automatic SSE-KMS encryption, clients can specify an EK as part of the write operation instead.

SILO can encrypt backend IAM/configuration data through the configured KMS. You can clear a bucket default with mcli encrypt clear, but existing encrypted data still requires its original keys. Do not remove the key service while that data depends on it.

SSE-KMS provides more granular and customizable encryption compared to SSE-S3 and SSE-C and is recommended over the other supported encryption methods.

For a tutorial on enabling SSE-KMS in a local (non-production) MinIO Deployment, see Quickstart.

MinIO supports enabling automatic SSE-S3 encryption of all objects written to a bucket using an EK stored on the external KMS. MinIO SSE-S3 supports one EK for the entire deployment.

For buckets without automatic SSE-S3 encryption, clients can request SSE encryption as part of the write operation instead.

SILO can encrypt backend IAM/configuration data through the configured KMS. You can clear a bucket default with mcli encrypt clear, but existing encrypted data still requires its original keys. Do not remove the key service while that data depends on it.

For a tutorial on enabling SSE-s3 in a local (non-production) MinIO Deployment, see Quickstart.

Clients specify an EK as part of the write operation for an object. SILO uses the client-supplied key for SSE-C. SSE-C does not require KES or a server-side KMS.

SSE-C does not support bucket-default encryption settings and requires clients perform all key management operations.

1 - Server-Side Object Encryption with KES

Deploy Silo with server-side object encryption

Use PGSTY KES as a separate key encryption service for SILO. Upstream MinIO KES is deprecated, but the maintained pgsty/kes fork has a published 20261026 release. KES is optional, independently released, and not embedded in the SILO binary.

The maintained integration is SILO → PGSTY KES → OpenBao KV v2. SILO encrypts object data; KES authenticates SILO and generates or decrypts data keys; OpenBao persists KES root keys. OpenBao uses KES’s keystore.vault configuration. See the integration design for the tested scope and upgrade boundaries.

Prerequisites

Access to the SILO Cluster

  • Install silo, mcli, and kes from Download & Install and verify their release checksums.
  • Configure an administrative mcli alias for SILO. Examples use mysilo.
  • Provide TLS certificates and trusted CA certificates for SILO, KES, and the key store. SILO must reach every configured KES endpoint; KES must reach the key store.
  • Back up existing data, configuration, and encryption keys before changing an established deployment.

Prepare the Persistent Key Store

Provision an OpenBao KV v2 mount and an AppRole with access to the KES key prefix; the OpenBao ACL example shows the required data and metadata paths. Configure these before starting KES. The following is a fragment of server-config.yaml, assuming a mount named kv and prefix kes:

keystore:
  vault:
    endpoint: https://openbao.example.net:8200
    engine: kv
    version: v2
    prefix: kes
    approle:
      id: "REPLACE_WITH_APPROLE_ID"
      secret: "REPLACE_WITH_APPROLE_SECRET"

Use the PGSTY KES configuration reference for the complete configuration, including TLS trust for the key store. Protect the configuration file and provision real credentials outside source control. Keep OpenBao unsealed and test its backup and recovery procedure.

Other inherited backends remain in the configuration reference. Archived guides cover AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager. Validate the chosen backend and authentication method separately.

Procedure

1. Configure KES Identities and TLS

Generate an application identity for SILO:

kes identity new

Keep the generated API key secret. Place the corresponding identity hash, not the API key, in the KES policy. Use a separate administrator identity to manage KES.

This policy fragment permits SILO to use keys whose names start with silo-:

policy:
  silo:
    allow:
      - /v1/key/create/silo-*
      - /v1/key/generate/silo-*
      - /v1/key/decrypt/silo-*
    identities:
      - "REPLACE_WITH_SILO_IDENTITY_HASH"

Combine the key store and policy fragments with address, admin.identity, and the tls.key/tls.cert settings from the configuration reference. The TLS certificate must cover the hostname SILO uses. API-key authentication and an explicitly supplied client key/certificate are alternative SILO authentication methods; do not configure both.

Start the configured service:

kes server --config /etc/kes/server-config.yaml

For containers, mount the configuration and certificates where the KES process can read them. The PGSTY KES image runs as UID/GID 1000:1000. KES packages provide the executable; provision configuration and service management separately.

2. Create the Keys

On an administrative host that trusts the KES server certificate, set the KES CLI credentials and create the default key and an optional bucket key:

export MINIO_KES_SERVER=https://kes.example.net:7373
export MINIO_KES_API_KEY='REPLACE_WITH_KES_ADMIN_API_KEY'
kes key create silo-default
kes key create silo-bucket

For an existing deployment, retain its original key names and key material. Creating a new key with an old name does not recover data encrypted under the original key.

3. Configure SILO

Set these values in the environment used by every SILO server process. With the supplied systemd unit, use /etc/default/silo:

MINIO_KMS_KES_ENDPOINT=https://kes.example.net:7373
MINIO_KMS_KES_API_KEY='REPLACE_WITH_SILO_API_KEY'
MINIO_KMS_KES_CAPATH=/etc/silo/certs/kes-ca.crt
MINIO_KMS_KES_KEY_NAME=silo-default

MINIO_KMS_KES_CAPATH is a CA file or directory on the SILO host, not a path inside the KES container. It can be omitted when the KES certificate chains to a CA already trusted by SILO. Multiple KES endpoints are comma-separated and must expose the same keys and policies.

The supplied unit reads /etc/default/minio first for migration compatibility and /etc/default/silo second. Use the file actually configured by your service manager. SILO itself loads an environment file only when MINIO_CONFIG_ENV_FILE selects one; see the environment-file reference.

Do not also set the MINIO_KMS_SERVER or static-key variable groups. See KES settings for mutually exclusive authentication and backend settings.

4. Restart and Check the Deployment

Ensure KES and its key store are available, then apply the environment changes through your service manager on every node. For systemd, restart silo.service as part of a coordinated deployment restart. mcli admin service restart reuses the process environment; it does not make systemd reread an edited EnvironmentFile.

Warning

Once SILO has encrypted backend IAM/configuration data or objects, preserve the keys and a working decryption path. Removing the KES settings or losing the key store can make the deployment or its objects unreadable. Clearing a bucket’s default encryption does not decrypt existing data.

5. Enable Bucket Encryption and Verify a Read

Using the configured mysilo alias and the keys above:

mcli mb mysilo/encryptedbucket
mcli encrypt set sse-kms silo-bucket mysilo/encryptedbucket
mcli encrypt info mysilo/encryptedbucket
printf 'SILO encryption check\n' > encryption-check.txt
mcli cp encryption-check.txt mysilo/encryptedbucket/
mcli stat mysilo/encryptedbucket/encryption-check.txt
mcli cat mysilo/encryptedbucket/encryption-check.txt

Use mcli encrypt set sse-s3 mysilo/encryptedbucket to use the deployment’s default key instead. Bucket defaults apply to new writes and do not retroactively encrypt existing objects. Test decryption again after restarting SILO and KES to avoid relying only on cached keys.

Kubernetes Deployments

In Kubernetes environments, run PGSTY KES as a separately managed service, inject its endpoint, credentials, and CA certificate into the SILO pods via ConfigMaps and Secrets, and pin the SILO and KES image tags independently.

The retained MinIO Operator guides document the archived upstream v7.1.1 compatibility snapshot (Operator Console was removed in v6.0.0, so do not follow legacy Console encryption screens). If you adapt historical TenantSpec.kes examples, verify that container permissions (1000:1000) and certificate mount paths match the PGSTY KES image.