PGSTY KES 20261018 Released
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 remainsgithub.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/configand 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 updateself-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).
Configure TLS certificates, mTLS client identity policies, and a persistent key store before starting KES in production (development mode stores keys only in memory). Official containers run as non-root UID/GID 1000:1000, so mounted configuration files and certificates must be readable by that user; Linux RPM/DEB/APK packages install /usr/local/bin/kes without starting an unconfigured service.
Back up your key store and configuration before upgrading, then verify decryption of existing objects, creation of new encrypted objects, and cold readback after restarting both KES and SILO.
Delivery and validation
All 19 release assets (6 Linux/macOS/Windows amd64/arm64 archives, 6 Linux RPM/DEB/APK packages, an archive checksum manifest, and 6 package checksum sidecars) were verified across downloaded digests, binary source/platform stamps, package payloads, both RPM signatures, and 11 GitHub build attestations (release workflow).
The official multi-arch (linux/amd64 and linux/arm64) container image docker.io/pgsty/kes:RELEASE.2026-10-18T00-00-00Z (Docker publication run) has index digest:
The primary verified integration stack is SILO + PGSTY KES + OpenBao KV v2 (covering mTLS authentication, OpenBao AppRole access, DEK wrap/unwrap, restart persistence, unauthenticated request rejection, and interoperability/rollback matrices across SILO 20260903/20260916 and upstream KES 2025-03-12T09-35-18Z, with AWS Secrets Manager protocol and storage regression coverage via Moto).
Download KES · Configuration and installation · Artifact verification · Changes since upstream.