Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) - Mailing list pgsql-hackers

From Jeremy Schneider
Subject Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Date
Msg-id 42b3e613-f18d-d0f3-a15d-6d6d1e4812b3@amazon.com
Whole thread Raw
In response to Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
List pgsql-hackers
On 3/3/19 21:40, Masahiko Sawada wrote:
> On Sat, Mar 2, 2019 at 5:27 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> To be honest, I think there is a lot to like about the patches
>> Cybertec has proposed.  Those patches don't have all of the fancy
>> key-management stuff that you are proposing here, but maybe that
>> stuff, if we want it, could be added, rather than starting over from
>> scratch.  It seems to me that those patches get a lot of things right.
>> In particular, it looked to me when I looked at them like they made a
>> pretty determined effort to encrypt every byte that might go down to
>> the disk.  It seems to me that you if you want encryption, you want
>> that.
> 
> Agreed. I think the patch lacks the key management stuff: 2-tier key
> architecture and integration of postgres with key management systems.
> I'd like to work together and can propose the patch of key management
> stuff to the proposed patch.

Might it make sense to generalize a little bit to secret management? It
would be *great* if PostgreSQL could have a standard "secrets" API which
could then use plugins or extensions to provide an internal
implementation (software or hardware based) and/or plug in to an
external secret management service, whether an OSS package installed on
the box or some 3rd party service off the box.

The two obvious use cases are encryption keys (mentioned here) and
passwords for things like logical replication, FDWs, dblinks, other
extensions, etc. Aside from adding new encryption key secrets, the way
PostgreSQL handles the existing secrets it already has today leaves room
for improvement.

-Jeremy

-- 
Jeremy Schneider
Database Engineer
Amazon Web Services


pgsql-hackers by date:

Previous
From: Jeremy Schneider
Date:
Subject: Re: Should we increase the default vacuum_cost_limit?
Next
From: Alvaro Herrera
Date:
Subject: Re: performance issue in remove_from_unowned_list()