KMS: Centralised Key Management for Modern Infrastructure

Why Not Just Store Keys in a File?

Encryption without proper key management is security theatre. Keys stored in config files, environment variables, or code repositories have predictable failure modes:

Leaked via CI/CD logs
Exfiltrated through compromised containers
Rotated rarely (or never)
Accessible to too many people

A Key Management Service (KMS) solves all of these by acting as a hardened, centralised vault for cryptographic keys.

How KMS Works

A KMS (like AWS KMS, Azure Key Vault, GCP Cloud KMS, or HashiCorp Vault) provides:

Key generation — Keys are created inside the HSM boundary (FIPS 140-3 validated). The raw key material never appears in plaintext outside the service.
Key storage — Encrypted by a root HSM key. At rest, always encrypted.
Key usage — You send data to the KMS to encrypt/decrypt. The key never leaves.
Key rotation — Automatic or on-demand rotation with version tracking (AWS key rotation).
Audit logging — Every use of a key is logged (who, when, what operation) for compliance with SOC 2, PCI DSS, and HIPAA.

Envelope Encryption

Encrypting large data directly with an HSM key is slow and expensive. KMS services use envelope encryption (NIST SP 800-57):

graph LR
    classDef kek fill:#e8f0fe,stroke:#0071e3,stroke-width:1px,color:#1d1d1f
    classDef dek fill:#f5f5f7,stroke:#d2d2d7,stroke-width:1px,color:#1d1d1f
    classDef data fill:#ffffff,stroke:#d2d2d7,stroke-width:1px,color:#1d1d1f
    classDef kms fill:#f0edff,stroke:#5856d6,stroke-width:1px,color:#1d1d1f

    subgraph Encrypt["Encrypt"]
        direction TB
        D1["Plaintext Data"] --> E1["Encrypt with DEK"]
        DEK1["DEK<br/>(Data Encryption Key)"] --> E1
        E1 --> CT["Ciphertext"]
        KEK1["KEK<br/>(Key Encryption Key)"] --> W1["Wrap DEK"]
        DEK1 --> W1
        W1 --> WDEK["Wrapped DEK"]
    end

    subgraph Decrypt["Decrypt"]
        direction TB
        CT2["Ciphertext"] --> D2["Decrypt with DEK"]
        WDEK2["Wrapped DEK"] --> U1["Unwrap DEK with KEK"]
        KEK2["KEK<br/>(KMS)"] --> U1
        U1 --> DEK2["Plaintext DEK"]
        DEK2 --> D2
        D2 --> P2["Plaintext Data"]
    end

    class KEK1,KEK2 kek
    class DEK1,DEK2 dek
    class D1,CT,P2,CT2 data
    class W1,U1 kms

To decrypt: send the wrapped DEK to the KMS → KMS unwraps it with the KEK → return plaintext DEK → decrypt data locally. The DEK can be cached to reduce round-trips. The KEK never leaves the KMS boundary (AWS KMS docs, Azure Key Vault, GCP Cloud KMS).

Compliance and Standards

KMS is central to compliance frameworks:

Standard	KMS Requirement
SOC 2	Access controls, key rotation, audit
PCI DSS	Key separation, tamper detection
FedRAMP	FIPS 140-2 / 140-3 validated HSMs
GDPR	Encryption key access controls (Art. 32)
HIPAA	Encryption key management procedures (§164.312)

Common Use Cases

Database encryption — TDE (Transparent Data Encryption) master keys
Kubernetes secrets — Encrypt etcd data at rest via KMS provider plugin (K8s docs)
CI/CD signing — Sign container images and release artifacts
TLS certificate private keys — Store and serve to proxies and load balancers
Token signing — Sign JWTs for OIDC / OAuth

Choosing a KMS

Factor	Cloud KMS (AWS/Azure/GCP)	Self-Hosted (Vault)
Setup	Zero ops	Requires cluster
Audit	Built-in	Configurable
HSM backing	Yes	Optional
Cost	Per-key/per-request	Infrastructure
Multi-cloud	Native per cloud	Unified API

Many enterprises use both: cloud KMS for cloud-native workloads and Vault as a unified layer across on-prem and multi-cloud.

KMS turns key management from an ops headache into an auditable, policy-driven service. In a zero-trust world, if you’re not using a KMS, you’re one config file leak away from losing your encryption altogether.