Skip to content

PGSTY KES 20261018 Released

The first PGSTY Key Encryption Service release: AWS SDK v2, compatible stored keys, and verified OpenBao integration.

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).

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:

sha256:c2d1a63d15052dfd2854bec9db3fc6846dd74fd6fdf43079f338f36e7a3d5f04

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.