# MinKMS RELEASE.2026-07-17T11-53-00Z Released: 2026-07-17 This release adds PKCS#11 hardware security module (HSM) support, letting MinKMS seal and unseal its on-disk state with keys held on real hardware HSMs (Thales Luna, Entrust nShield, Utimaco, smartcards) and SoftHSM2, alongside the existing network-service backends. It also adds outbound mTLS client-certificate authentication for the Vault and OpenBao HSM backends, ships fully embedded terminal-discoverable CLI documentation, and hardens the on-disk cluster file against crashes. --- ## Downloads ### Binary Downloads | Platform | Architecture | Download | | -------- | ------------ | -------------------------------------------------------------------------------------------------- | | Linux | amd64 | [minkms.RELEASE.2026-07-17T11-53-00Z](https://dl.min.io/aistor/minkms/release/linux-amd64/archive/minkms.RELEASE.2026-07-17T11-53-00Z) | | Linux | arm64 | [minkms.RELEASE.2026-07-17T11-53-00Z](https://dl.min.io/aistor/minkms/release/linux-arm64/archive/minkms.RELEASE.2026-07-17T11-53-00Z) | | macOS | amd64 | [minkms.RELEASE.2026-07-17T11-53-00Z](https://dl.min.io/aistor/minkms/release/darwin-amd64/archive/minkms.RELEASE.2026-07-17T11-53-00Z) | | macOS | arm64 | [minkms.RELEASE.2026-07-17T11-53-00Z](https://dl.min.io/aistor/minkms/release/darwin-arm64/archive/minkms.RELEASE.2026-07-17T11-53-00Z) | | Windows | amd64 | [minkms.exe.RELEASE.2026-07-17T11-53-00Z](https://dl.min.io/aistor/minkms/release/windows-amd64/archive/minkms.exe.RELEASE.2026-07-17T11-53-00Z) | ### FIPS Binaries | Platform | Architecture | Download | | -------- | ------------ | -------------------------------------------------------------------------------------------------- | | Linux | amd64 | [minkms.RELEASE.2026-07-17T11-53-00Z.fips](https://dl.min.io/aistor/minkms/release/linux-amd64/archive/minkms.RELEASE.2026-07-17T11-53-00Z.fips) | Each binary also has `.sha256sum`, `.minisig`, and `.asc` signature files available at the same path. ### Container Images ```bash # Standard docker pull quay.io/minio/aistor/minkms:RELEASE.2026-07-17T11-53-00Z podman pull quay.io/minio/aistor/minkms:RELEASE.2026-07-17T11-53-00Z # FIPS docker pull quay.io/minio/aistor/minkms:RELEASE.2026-07-17T11-53-00Z.fips podman pull quay.io/minio/aistor/minkms:RELEASE.2026-07-17T11-53-00Z.fips ``` --- ## New Features ### PKCS#11 HSM Support (#235) MinKMS can now seal and unseal its root encryption key using a key stored on a PKCS#11 token, the standard interface for hardware HSMs such as Thales Luna, Entrust nShield, and Utimaco, as well as smartcards and software tokens like SoftHSM2. Previously, on-disk state could only be protected by network key-management services (Vault, OpenBao, KeyControl, MinKMS); this brings true hardware-backed key protection to MinKMS deployments. - Configured through a new `hsm.pkcs11.` config section specifying the module path, a token label **or** slot ID (mutually exclusive), the PIN, and the key label. - Sealing wraps a fresh random data key with AES on the token and encrypts data locally with AES-256-GCM; the same token key is used to derive the internode API key. Only the `CKM_AES_ECB` mechanism is used, and no IV is ever sent to the token, so FIPS-configured tokens that reject caller-supplied IVs work out of the box. - The PKCS#11 module (a C library) is driven by a small embedded helper process rather than linked in, so MinKMS keeps its `CGO_ENABLED=0`, static-binary build. The helper is embedded in Linux builds and runs from an in-memory file descriptor, so it works in scratch/read-only-root-filesystem containers with no filesystem writes. **Platform support:** PKCS#11 HSMs are supported on Linux (amd64 and arm64). On other platforms, configuring a PKCS#11 HSM returns an unsupported-backend error. **Operator notes:** - The sealed ciphertext format commits to the configured key label. Renaming the HSM config name or the key label orphans previously sealed data — treat these as immutable once initialized. - All cluster nodes must have access to the same token key, since it is used to derive the shared internode API key. ### Outbound mTLS Client Certificates for Vault and OpenBao (#228) The Vault and OpenBao HSM backends can now present a client certificate when connecting, enabling mutual-TLS authentication to Vault/OpenBao servers that require it. The client certificate and key are configured under a `tls.client_cert` section of the backend config. Custom root CAs configured for these backends are now consistently applied to the outbound TLS connection. --- ## Bug Fixes ### Storage - **Crash-safe cluster file writes (#234):** Writes to `cluster.json` are now fully atomic and durable. MinKMS writes to a temporary sibling file, fsyncs it, renames it into place, and fsyncs the parent directory, so a concurrent reader always sees either the complete old or complete new file — never a truncated or empty one — and the update survives a crash or power loss. This closes several latent gaps in the previous implementation: the parent directory was never fsynced (a crash could lose the rename), concurrent writers were not serialized, and a leftover `cluster.json.tmp` from a crashed write could cause **every subsequent write to fail permanently**. The file's permissions (`0o640`, umask-masked) are unchanged. --- ## Improvements - **Terminal-discoverable CLI documentation (#236):** Every `minkms` command and every major concept now has a proper man page embedded directly in the binary. Command help is available via `minkms --help` (and `-h`), and concept guides — covering HSMs, TLS, clustering, IAM, enclaves, keys, the server API, and configuration — are available via `minkms help `. Documentation now ships with the binary, with no external files or network access required, and is maintained as the single source of truth for CLI docs. --- ## Deprecations - **Password-protected server-certificate private keys (#230):** MinKMS now prints a deprecation warning when a password-encrypted private key is used for a server certificate. Encrypted private keys add operational complexity for little security benefit in this context, since the passphrase resides in the same config file as the key path. Operators using password-protected server-certificate keys should plan to migrate to unencrypted keys with appropriate filesystem permissions. --- ## Security & Compliance ### Software Bill of Materials (SBOM) This release includes comprehensive SBOM documentation in multiple formats: - [SPDX JSON](sbom-RELEASE.2026-07-17T11-53-00Z.spdx.json) - Standard SBOM format - [CycloneDX JSON](sbom-RELEASE.2026-07-17T11-53-00Z.cyclonedx.json) - Security scanner compatible - [Go Modules](go-modules-RELEASE.2026-07-17T11-53-00Z.txt) - Human-readable dependency list SBOM files document all direct and transitive dependencies for security auditing and compliance requirements. --- ## Upgrade Instructions MinKMS supports rolling upgrades. Upgrade one node at a time, starting with followers: 1. Stop the follower node 2. Replace the `minkms` binary 3. Start the node and wait for it to rejoin the cluster 4. Repeat for remaining followers 5. Upgrade the leader node last **Important**: Write operations require all nodes to be available. Plan a brief maintenance window for the leader upgrade. ### New Configuration Options - `hsm.pkcs11.` — configure a PKCS#11 HSM backend (module path, token label or slot ID, PIN, key label). See `minkms help hsm`. - `tls.client_cert` (Vault/OpenBao HSM backends) — client certificate and key for outbound mTLS authentication. ### Migration Notes No migration steps are required to upgrade. Existing HSM, TLS, and cluster configurations continue to work unchanged. New PKCS#11 and mTLS client-certificate options are opt-in. ### Support For enterprise support: - SUBNET Support: https://subnet.min.io - Documentation: https://docs.min.io