Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

From: Jeremy Schneider <schnjere(at)amazon(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Date: 2019-03-06 18:49:17
Message-ID: 42b3e613-f18d-d0f3-a15d-6d6d1e4812b3@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/3/19 21:40, Masahiko Sawada wrote:
> On Sat, Mar 2, 2019 at 5:27 AM Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-03-06 18:52:50 Re: performance issue in remove_from_unowned_list()
Previous Message Jeremy Schneider 2019-03-06 18:38:10 Re: Should we increase the default vacuum_cost_limit?