SILO, KES and OpenBao: Key Ownership and Recovery

Sun, 18 Oct 2026 00:00:00 +0000

SILO integrates with external key-management systems through PGSTY KES (MINIO_KMS_KES_ENDPOINT). PGSTY KES 20261018 (source 2f7e741db905) is deployed independently of the four-component SILO build graph and migrates the KES AWS Secrets Manager backend to AWS SDK for Go v2 while preserving existing SILO/KES key formats and OpenBao KV v2 compatibility.

Three services, three responsibilities

Service	Owns	Calls
SILO	Object bytes and object encryption metadata; encrypts/decrypts object contents	KES over HTTPS (mTLS) to generate/decrypt data keys
PGSTY KES	Application identities, key-access policies, and the key API; wraps/unwraps data keys	OpenBao KV v2 to store/retrieve root keys
OpenBao	Persistent KES root-key records, backend access control, and its own recovery material	Its configured storage backend

+-------------+       mTLS (KES API)       +-------------+    AppRole / TLS    +--------------------+
| SILO Server | -------------------------> |  PGSTY KES  | ------------------> | OpenBao (KV v1/v2) |
+-------------+  MINIO_KMS_KES_ENDPOINT    +-------------+   keystore.vault    +--------------------+

MINIO_KMS_KES_ENDPOINT must point to the KES endpoint because OpenBao does not implement the KES key-wrapping API. KES accesses OpenBao through its keystore.vault driver (version: v2 for OpenBao KV v2 mounts). The same kes executable provides both the server and the administration CLI, and multiple stateless KES instances can share a single OpenBao backend.

PGSTY KES 20261018 Released

Sun, 18 Oct 2026 00:57:52 +0800

Release: RELEASE.2026-10-18T00-00-00Z · Package: 20261018000000.0.0 · Source: 2f7e741db905.

This is the first maintained PGSTY release of the Key Encryption Service (KES). KES is a standalone stateless service for SILO deployments that require external KMS-backed server-side encryption (see the component matrix).

Changes

Establish PGSTY maintenance and release pipelines while preserving upstream copyright, attribution, and third-party licenses. The executable and system packages remain kes, and the Go module path remains github.com/minio/kes.
Build with Go 1.27.2, refresh dependencies, and migrate the AWS Secrets Manager backend from the deprecated AWS SDK for Go v1 to AWS SDK for Go v2. Preserve YAML configuration fields, explicit credential precedence, custom endpoints, and stored key formats (continuing to ignore ~/.aws/config and SDK endpoint environment overrides).
Preserve the KES HTTP API, MINIO_KMS_KES_* configuration settings, existing root keys, and encrypted objects so existing SILO + KES deployments can upgrade in place without key migration.
Add upgrade, rollback, and restart integration suites pairing SILO with OpenBao KV v2 and the Moto Secrets Manager emulator, restarting SILO at each version transition so in-memory key caches cannot mask compatibility regressions.
Ship signed Git tags, GitHub build provenance attestations, GPG-signed RPMs, and non-root container images, with the built-in kes update self-updater disabled.

Deployment and upgrade

In a server-side encryption deployment, SILO encrypts object contents, KES authenticates mTLS client requests and wraps or unwraps data encryption keys (DEKs), and OpenBao persists the root key encryption keys (KEKs). Point MINIO_KMS_KES_ENDPOINT at KES, not OpenBao (see the KES and OpenBao design note for architecture boundaries and recovery requirements).

KES on SILO

SILO, KES and OpenBao: Key Ownership and Recovery

Three services, three responsibilities

PGSTY KES 20261018 Released

Changes

Deployment and upgrade