Thanks all for the discussions. New to PostgreSQL so don't have much context here.
Regarding the multiple clusters idea, how does that work? Assume we can store one customer's data in one cluster, is it possible to have separate KEK for different clusters?
Why not using multiple clusters then?
Better isolation of the customers, but still on one server.
On Thu, May 18, 2023 at 3:53 PM Stephen Frost <sfrost@snowman.net> wrote:
Greetings,
Please don't top-post on these lists.
* Tony Xu (tony.xu@rubrik.com) wrote: > Our use-case is for a multi-tenancy scenario - we are considering using > different databases to store different customer's data, however, for > cost-efficiency, we want to host them in the same server (to reduce the > CPU/mem idle time and to reduce the server management efforts). Now there > is a compliance related feature that we need to let our customer control > the KEK for their databases so they can rotate their KEKs independently, so > we cannot use one KEK for the whole PG server. Conceptually, different > databases are independent of each other, it also makes sense to allow them > to have completely independent encryption facilities?
This really isn't currently in the plans and while it might be something added later, as pointed out farther down on this thread, it wouldn't be possible for the shared catalogs or the WAL to have separate keys for those things which are relevant to a database, so it's not like each tenant would actually have control over the key for "all" of their data (consider that roles are stored in a shared PG catalog and then shared among databases...).
To meet this compliance requirement, you'd certainly be much more able to blanket claim that everything is independent by having a separate PG instance for each client. This would also allow rather useful things like being able to do a file-based restore on a per-client basis in the event something happens, rather than having to roll back an entire cluster to some point in time just because one client did something bad.. You'd also be able to scale the number of systems supporting a given client independently.
