Re: Would PostgreSQL 16 native transparent data encryption support database level encryption? - Mailing list pgsql-general

From Tony Xu
Subject Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?
Date
Msg-id CACufLfzWQT9sQ6eaycvzehV76OeWKTtG7FTv5LVxpAEgJR7f4Q@mail.gmail.com
Whole thread Raw
In response to Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?  (Thorsten Glaser <tg@evolvis.org>)
Re: Would PostgreSQL 16 native transparent data encryption support database level encryption?  (Stephen Frost <sfrost@snowman.net>)
List pgsql-general
Thanks for the information,  Andreas, Stephen.

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? 

Thanks,
Tony



On Thu, May 18, 2023 at 8:54 AM Stephen Frost <sfrost@snowman.net> wrote:
Greetings,

* Tony Xu (tony.xu@rubrik.com) wrote:
> The FAQ (copied below) mentioned that native transparent data encryption
> might be included in 16. Is it fair to assume that it will support database
> level encryption, that is, we can use two encryption keys for two databases
> in the same server, respectively? How can one verify that?

The current work to include TDE in PG isn't contemplating a per-database
key option.  What's the use-case for that?  Why do you feel that you'd
need two independent keys?  Also, the general idea currently is that
we'll have one key provided by the user which will be a KEK and then
multiple DEKs (different ones for relation data vs. temporary data vs.
the WAL).

If you're interested in TDE in PG, we could certainly use more folks
being involved and working to push it forward.

Thanks,

Stephen

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: JSONB operator unanticipated behaviour
Next
From: "Arora, Nick"
Date:
Subject: Unrecognized Node Type Warning