In the Dark Gravity Autonomous CA/CD Software Factory (V7.2 / V7.3), KES is not merely a utility—it is the critical Key Management Service (KMS) proxy that governs all envelope encryption operations, data-at-rest protection, and cryptographic key lifecycle management for the entire autonomous engineering system.

Upstream MinIO's deprecation of KES open-source leaves unaddressed security vulnerabilities (CVEs) and orphaned cryptographic primitives. In a zero-trust, autonomous multi-agent factory where AI agents autonomously synthesize, compile, and deploy software:

• Envelope Encryption Integrity: KES mediates all Data Encryption Key (DEK) derivation between MinIO Object Storage and the root KMS (HashiCorp Vault, AWS KMS, GCP KMS, Azure Key Vault). Unpatched vulnerabilities in the key proxy would compromise every encrypted object in the factory.
• Cryptographic Provenance Chain: Every artifact produced by the Dark Gravity factory—compiled binaries, AST mutations, causal lineage snapshots—relies on KES-derived keys for at-rest encryption. A broken KES link invalidates the entire cryptographic proof chain.
• Air-Gapped Data Sovereignty: Dark Gravity operates on sovereign, air-gapped infrastructure. Key material must never escape the private network perimeter, and the KMS proxy must remain fully auditable and patchable without commercial dependencies.
• Continuous Compliance & Auditability: Under regulations like the EU AI Act (Art. 12 & 14), SOC 2 Type II, and ISO/IEC 25059, any weakness in key management voids the factory's compliance posture.

Therefore, this repository is actively maintained to remediate security flaws, patch cryptographic vulnerabilities, and provide robust CI/CD builds tailored for production Kubernetes and MicroK8s environments.

KES is the central cryptographic gateway bridging MinIO Object Storage with enterprise Key Management Systems:

graph TD
    subgraph "MicroK8s Cluster (storage namespace)"
        MINIO["MinIO Tenant S3 Storage<br/>(mlflow-minio-pool-0)"]
    end

    subgraph "KES Key Encryption Service"
        KES_NODE["KES Server<br/>(Stateless, Horizontally Scalable)"]
    end

    subgraph "Root Key Management Systems"
        VAULT["HashiCorp Vault"]
        AWS_KMS["AWS KMS / Secrets Manager"]
        GCP_KMS["GCP Secret Manager"]
        AZURE_KV["Azure Key Vault"]
        FORTANIX["Fortanix SDKMS"]
        ENTRUST["Entrust KeyControl"]
        GEMALTO["Gemalto KeySecure"]
    end

    subgraph "Dark Gravity Factory Core"
        HATCHET["Hatchet DAG Engine<br/>(Crash Resilience)"] -->|Encrypted BridgeState Checkpoints| MINIO
        ZERO_CLAW["ZeroClaw / Rustant<br/>(Code Execution)"] -->|Encrypted Spec-Kit & Code Artifacts| MINIO
        SEMANTICA["Semantica-AGI<br/>(Causal Graph)"] -->|Encrypted Ontological Lineage Snapshots| MINIO
        MLFLOW["MLflow Tracking Server"] -->|Encrypted Model Weights & Partitions| MINIO
    end

    MINIO -->|DEK Request / Envelope Encryption| KES_NODE
    KES_NODE -->|Root Key Operations| VAULT
    KES_NODE -.->|Alternative KMS| AWS_KMS
    KES_NODE -.->|Alternative KMS| GCP_KMS
    KES_NODE -.->|Alternative KMS| AZURE_KV
    KES_NODE -.->|Alternative KMS| FORTANIX
    KES_NODE -.->|Alternative KMS| ENTRUST
    KES_NODE -.->|Alternative KMS| GEMALTO

• Cluster Topology & Service Endpoints: KES is deployed as a stateless service in the storage Kubernetes namespace, fronting MinIO's Server-Side Encryption (SSE-S3/SSE-KMS) with horizontal auto-scaling.
• Envelope Encryption Flow: MinIO requests Data Encryption Keys (DEKs) from KES. KES derives DEKs using root keys stored in the configured KMS backend (Vault, AWS, GCP, Azure, etc.), returning both the plaintext DEK (for encryption) and the sealed DEK (for storage alongside encrypted data).
• Stateless Architecture: KES nodes maintain no persistent state—all key material is derived on-demand from the root KMS, enabling seamless scaling and zero-downtime upgrades.

To protect the factory's cryptographic infrastructure against compromise, the following defenses are strictly enforced:

• mTLS Identity Verification: All KES API access requires mutual TLS authentication. Client certificates are mapped to KES identities with policy-based access control.
• Policy-Based Key Access Control: Fine-grained policies restrict which identities can create, derive, decrypt, or list keys, preventing unauthorized key operations.
• Audit Logging: Every cryptographic operation (key creation, DEK derivation, decryption) is logged with full identity context for compliance audit trails.
• Prometheus Metrics & Monitoring: KES exposes /v1/metrics for real-time observability of cryptographic operations, error rates, and latency.
• Cryptographic Provenance (NHI Verifiable Credentials): Every artifact and code modification is cryptographically signed by Non-Human Identities (NHI) using W3C Verifiable Credentials with Ed25519 keys and deterministic BLAKE3/SHA-256 hashes.

KES is a cloud-native distributed key management and encryption server designed to secure modern applications at scale.

• What is KES?
• Installation
• Quick Start
• Documentation

KES (Key Encryption Service) is a distributed key management server that scales horizontally. It can either be run as edge server close to the applications reducing latency to and load on a central key management system (KMS) or as central key management service. KES nodes are self-contained stateless instances that can be scaled up and down automatically.

We designed KES as Open Source software for the Open Source software community. We encourage the community to remix, redesign, and reshare KES under the terms of the AGPLv3 license.

All usage of KES in your application stack requires validation against AGPLv3 obligations, which include but are not limited to the release of modified code to the community from which you have benefited.

The AGPLv3 provides no obligation by any party to support, maintain, or warranty the original or any modified work. All support is provided on a best-effort basis through GitHub, and any member of the community is welcome to contribute and assist others in their usage of the software.

The KES server and CLI is available as a single binary, container image or can be built from source.

docker pull lgcorzo/kes

curl -sSL --tlsv1.2 'https://github.com/lgcorzo/kes/releases/latest/download/kes-<OS>-<ARCH>' -o ./kes

chmod +x ./kes

curl -sSL --tlsv1.2 'https://github.com/lgcorzo/kes/releases/latest/download/kes-<OS>-<ARCH>.minisig' -o ./kes.minisig

minisign -Vm ./kes -P RWTx5Zr1tiHQLwG9keckT0c45M3AGeHD6IvimQHpyRywVWGbP1aVSGav

go install github.com/lgcorzo/kes/cmd/kes@latest

We run a public KES instance at https://play.min.io:7373 as playground. You can interact with our play instance either via the KES CLI or cURL. Alternatively, you can get started by setting up your own KES server in less than five minutes.

export KES_SERVER=https://play.min.io:7373
export KES_API_KEY=kes:v1:AD9E7FSYWrMD+VjhI6q545cYT9YOyFxZb7UnjEepYDRc

kes key create my-key

kes key dek my-key

If you want to learn more about KES checkout our documentation.

• Integration Guides
• Command Line
• Server API
• Go SDK

KES servers provide an API endpoint /v1/metrics that observability tools, like Prometheus, can scrape.
Refer to the monitoring documentation for how to setup and capture KES metrics.

For a graphical Grafana dashboard refer to the following example.

To guarantee long-term sovereign support, full supply-chain independence, and continuous security patching for the Dark Gravity factory and production environments, the complete MinIO ecosystem of 38 servers, clients, storage drivers, acceleration libraries, and core dependencies has been preserved and actively maintained under @lgcorzo:

To preserve long-term operational resilience, supply-chain autonomy, and enterprise security compliance (EU AI Act, SOC 2 Type II, ISO 25059) without upstream commercial lock-in, all 38 repositories are managed under a structured maintenance protocol:

flowchart TD
    subgraph "1. Upstream & Vulnerability Tracking"
        UPSTREAM["Upstream Git Repositories"] -->|Weekly Cron Poll| SYNC_WF["GitHub Actions: Upstream Sync"]
        VULN_DB["OSV / NIST NVD / VulnCheck"] -->|Daily Security Scan| SEC_SCAN["Trivy & CodeQL SAST"]
    end

    subgraph "2. Autonomous Remediation (Dark Gravity Factory)"
        SYNC_WF -->|New Commits / Upstream Tags| MERGE_GATE{"Conflict Check"}
        SEC_SCAN -->|CVE Alert Detected| ISSUE_DISPATCH["Dispatch Mission to Hatchet DAG"]
        ISSUE_DISPATCH --> RUSTANT["Rustant Planner Agent"]
        RUSTANT --> ZERO_CLAW["ZeroClaw Dev Agent"]
        ZERO_CLAW -->|AST Surgical Fix| BRANCH_PR["Create Hardened PR"]
    end

    subgraph "3. Automated Verification Matrix"
        MERGE_GATE -->|Fast-Forward / Non-Conflicting| RUN_MATRIX["Comprehensive CI Matrix"]
        BRANCH_PR --> RUN_MATRIX
        RUN_MATRIX --> TEST_BUILD["Build & Vet (Go 1.25)"]
        RUN_MATRIX --> TEST_LINT["golangci-lint v2"]
        RUN_MATRIX --> TEST_MULTI["Test Matrix (Linux, Windows, macOS)"]
        RUN_MATRIX --> TEST_VULN["govulncheck Security Scan"]
        RUN_MATRIX --> TEST_RELEASE["GoReleaser Snapshot Build"]
    end

    subgraph "4. Supply Chain Artifact Publishing"
        RUN_MATRIX -->|Green Verification| BUILD_ARTIFACTS["Multi-Arch Build (AMD64 / ARM64)"]
        BUILD_ARTIFACTS --> DOCKER_REG["GHCR (ghcr.io/lgcorzo/kes)"]
        BUILD_ARTIFACTS --> QUAY_REG["Quay.io (quay.io/lgcorzo/kes)"]
        BUILD_ARTIFACTS --> GH_RELEASES["GitHub Releases + Minisign Signatures"]
    end

• Scheduled Synchronization Workflows: Each repository runs a weekly GitHub Actions workflow fetching upstream tags and release commits.
• Protected Branch Non-Destructive Merges: Upstream changes are fetched into dedicated tracking branches and merged into master via pull requests to ensure custom factory hardening and Dark Gravity patches are never overwritten.

• Continuous CVE Scanning: Daily VulnCheck, CodeQL, and govulncheck inspections are executed across all repositories.
• Autonomous Repair via Dark Gravity Agents:
  1. High/Critical CVEs trigger an issue labeled autonomous-mission in rust_CACD_autonomous_factory.
  2. The Hatchet orchestrator assigns the remediation mission to ZeroClaw (developer agent).
  3. Surgical AST mutations are applied, tested in gVisor sandboxes against the standardized verification suite, and presented for Human-in-the-Loop (HITL) review.

• GoReleaser Multi-Arch Builds: KES produces linux/amd64 and linux/arm64 binaries and container images via GoReleaser.
• Dual Registry Target:
  • Global Container Distribution: ghcr.io/lgcorzo/kes:latest and quay.io/lgcorzo/kes:latest.
  • Air-Gapped MicroK8s Deployments: In-cluster private registry at localhost:32000.

• Every published binary (kes) is cryptographically signed using Minisign, generating signature files for supply-chain provenance verification.
• Downstream container images verify checksums before packaging to enforce strict supply-chain provenance.

To import sovereign libraries across the Dark Gravity factory without namespace conflicts, projects declare Go module replace directives in their go.mod:

module my-factory-service

go 1.25

require (
    github.com/minio/kes v0.0.0
    github.com/minio/kms-go/kes v0.3.1
)

replace (
    github.com/minio/kes => github.com/lgcorzo/kes master
    github.com/minio/kms-go => github.com/lgcorzo/kms-go master
)

Please follow KES Contributor's Guide for guidance on making new contributions to the repository.

• KES source is licensed under the GNU AGPLv3.
• Use of KES is governed by the AGPLv3 license that can be found in the LICENSE file.