Server-Side Object Encryption with KES

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.

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.