Customer-held encryption keys (KMS/HSM) issue #251 open andymccall opened this 18 days ago · 1 comment

Let an organisation hold the keys that protect its data, in its own KMS or HSM, in its own jurisdiction.

Levels, cheapest first:

• Storage at rest: customer-managed keys for Strata buckets (S3 SSE-KMS, GCS CMEK). Mostly passing a key ID through.
• Hub secrets (Flow secrets, secrets.key): encrypt them with a data key, and keep the key that wraps it in the customer's KMS or HSM.
• The hub's signing key in an HSM/KMS: this matters most since keyless (issue #241), because that key issues every short-lived certificate and is the root of trust. Open question: the composite signature has an ML-DSA part, and KMS support for ML-DSA is new; check it before promising anything.

Not in scope: encrypting repository content so that even the host cannot read it. That conflicts with browsing, search and diffs.

Low priority: after the core work.