Skip to content

Why KeyRack

KeyRack is an open-source key management service (KMS) that runs in your infrastructure, on your terms.

Every major cloud provider ships a KMS. They work well — until they don’t.

Cloud KMS ties encryption keys to the provider’s platform. Migrating means re-encrypting every piece of data with new keys — often the single biggest blocker to cloud migration.

Cloud providers manage the HSMs. “Customer-managed keys” still mean the provider’s HSM, firmware, and physical security.

You receive audit logs but cannot independently verify their completeness or integrity. There is no cryptographic proof that no entries were omitted.

When a tenant needs to cut off platform access, there is no guaranteed mechanism for immediate key revocation. The gap between “revoke” and “actually unusable” is provider-controlled.

Each cloud KMS has its own API. Multi-cloud architectures end up with per-provider encryption code, key management, and audit trails.

KeyRack handles key lifecycle management and cryptographic operations without giving a third party access to your keys. It is software you operate — the security boundary is yours to define.

KeyRack separates key management logic from cryptographic operations. Supported backends today:

  • PKCS#11 — FIPS 140-3 certified HSMs (Thales Luna, Entrust nShield, YubiHSM, AWS CloudHSM, SoftHSM for development)
  • KMIP client — remote key servers and HSMs speaking the OASIS standard
  • Vault Transit — HashiCorp Vault-backed operations
  • Software — in-process RustCrypto for development and testing

Switch providers without changing application code. Your key hierarchy, policies, and audit trail remain intact.

Tenants provision their own HSM or KMIP-compatible crypto backend. KeyRack manages the key hierarchy on top — the root key never leaves the tenant’s HSM. Disconnect the HSM and all derived keys become unusable within a configurable cache TTL.

Every operation emits an audit event with Ed25519 signature, BLAKE3 hash-chain linking, and full operation metadata. The trail is independently verifiable. Events are delivered via NATS for real-time consumption.

Existing AWS SDK or OpenStack clients can talk to KeyRack unchanged via the commercial AWS KMS and Barbican shims — see Commercial extensions. For a FOSS-first step that keeps crypto on AWS, the keyrack-aws-proxy adds visibility with zero code changes (Brownfield migration).

  • Regulated industries — DORA, NIS2, HIPAA, PCI-DSS, or national data sovereignty requirements
  • Multi-cloud platforms — single KMS interface across AWS, Azure, GCP, or private cloud
  • SaaS providers — HYOK model for enterprise customers who hold their own keys
  • OpenStack operators — real tenant key isolation with cascade-disable and PDP authorization
FeatureCloud KMSKeyRack
Key sovereigntyProvider-controlled HSMCustomer-controlled (PKCS#11/KMIP)
Audit verifiabilityProvider-generated logsEd25519-signed hash chain
Instant revocationProvider-dependentBounded by configurable cache TTL
Multi-cloud portableNoYes (single KMS)
HYOKLimitedFull: tenant-managed HSM
AuthorizationIAM (provider-specific)Cedar policy-as-code
Open sourceNoCore is AGPL-3.0-or-later