cratefield-kms 0.2.0

Cratefield harness KMS port: wrap and unwrap data keys, with a local-file provider for development
Documentation

cratefield-kms

The KMS port (issue #40, ADR 0102, docs/SECRETS-DESIGN.md). Wrapping and unwrapping a data key is the only thing the KMS does for the harness, so it is the only thing this trait can ask; the cipher that seals a secret, the data that binds a ciphertext to its row, and where the wrapped key is stored all belong elsewhere.

LocalFileKms is the development provider. It uses the same real AEAD, but its master key sits on a local disk where anything that can read the file can read the key, so it refuses to construct when the environment is production.

WorkerSecretKms (issue #535, ADR 0103) is the production provider for the Cloudflare path. Its KEK is a versioned set of Worker secrets — HARNESS_KEK_CURRENT names the version that wraps, HARNESS_KEK_V1, HARNESS_KEK_V2, … hold the material — read once at construction, and unwrap dispatches on the version header in the blob, so rotation is put the next version, point, redeploy, re-wrap, delete (docs/KEY-ROTATION.md). It does not refuse production: the KEK lives in the platform's secret store, never on a host disk. It is not an HSM KMS and is not claimed as one.

Managed providers (AWS KMS, Google Cloud KMS) are not implemented yet: they need credentials and a nightly job against the real service, and an unexercised vendor integration in this position is worse than an absent one.


MIT. Built in the open for Cratefield, a Factory Zero venture.