pH14
commented
2 months ago A few thoughts that might help future work on CMEK...
- We'll almost certainly need to do client-side encryption. S3 does not give us what we need for anything built in, and our Consensus data needs to be encrypted as well. If we do client-side correctly, it's a stronger guarantee than using the server-side options too
- Currently, the data in Consensus that requires encryption is just stats. Personally don't see a need to encrypt anything else
For implementation, I imagine all the work can be pushed down into persist. A few possible ideas there:
- Encryption is handled at the data-format level, and potentially wrapped up behind
EncryptedBlobandEncryptedConsensusimplementations, that sit as the lowest level of the chain. They transparently add in encryption of the data / data keys, and are given a client that allows them to decrypt the data keys via customer-managed key if available. - Alternatively, encryption is fully baked in at all levels of persist. One could imagine using shard state transitions to indicate new store / data keys that are shared across all writers
Alternatively, we could rejig our cloud infra to be single tenant and do something super simple:
- Dedicated S3 bucket with SSE-KMS hooked up to the customer key
- Dedicated CRDB cluster with CMEK hooked up to the customer key
Notion epic
Link: https://www.notion.so/Customer-Managed-Encryption-Keys-CMEK-96457aba99a743f98c170fc29ec4ddc6 Product brief: Status: Not started Prioritization: 10 - October Estimated delivery date:
Migrated from MaterializeInc/product#221.
A user in the community asked about our support for CMEK for encryption at rest, and mentioned it as a blocker for their use case. Their specific need was for keys stored in AWS-KMS.
See this thread for more context.
cc @morsapaes