OK. I went down the rabbit hole to see what GCP has WRT per-user encryption. TL;DR: customer-managed encryption keys can be used but this is mostly useful when using a GCP service that doesn’t already encrypt all the data stored. Firestore is one such service where all data is already encrypted and the keys are automatically managed by Google, including rotation.
The purpose of this isn’t to prevent GCP admins from reading the data. And this was my goal. Sadly it’s just not a supported feature. The assumption is that you as the owner of the app will want or need access to all the data your customers submit.
One way to avoid this would require full E2E encryption, which is tricky to get right without impacting UX. Storing the encryption keys in firebase is a possibility and would make for a slightly friendlier UX (where keys are managed on behalf of the user as opposed to letting them do that). This would mean that admins can still technically can decrypt user’s data though, which I’m not sure I would be comfortable with.
I mean, there’s a possibility the UX doesn’t have to be terrible. An easy assumption could be made that the user would stick mostly to a single device, where their private key can be stored in local storage. Syncing devices could be done via QR code to avoid sending the key across the network.
Apparently Google has written a client-side encryption library Tink that can be used together with KMS to provide client-side encryption of user data. The user key is generated and stored locally, and then “wrapped” by encrypting it together with the encrypted object using the KMS key (I think).
Anyway, I’m way too tired to be figuring all this out right now. I need to go sleep.