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

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "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-06-17 14:02:23
Message-ID: 20190617140223.2cfumi5c2gverups@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 17, 2019 at 08:39:27AM -0400, Joe Conway wrote:
>On 6/17/19 8:29 AM, Masahiko Sawada wrote:
>> From perspective of cryptographic, I think the fine grained TDE would
>> be better solution. Therefore if we eventually want the fine grained
>> TDE I wonder if it might be better to develop the table/tablespace TDE
>> first while keeping it simple as much as possible in v1, and then we
>> can provide the functionality to encrypt other data in database
>> cluster to satisfy the encrypting-everything requirement. I guess that
>> it's easier to incrementally add encryption target objects rather than
>> making it fine grained while not changing encryption target objects.
>>
>> FWIW I'm writing a draft patch of per tablespace TDE and will submit
>> it in this month. We can more discuss the complexity of the proposed
>> TDE using it.
>
>+1
>
>Looking forward to it.
>

Yep. In particular, I'm interested in those aspects:

(1) What's the proposed minimum viable product, and how do we expect to
extend it with the more elaborate features. I don't expect perfect
specification, but we should have some idea so that we don't paint
ourselves in the corner.

(2) How does it affect recovery, backups and replication (both physical
and logical)? That is, which other parts need to know the encryption keys
to function properly?

(3) What does it mean for external tools (pg_waldump, pg_upgrade,
pg_rewind etc.)?

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-06-17 14:26:49 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Previous Message Robert Haas 2019-06-17 13:59:50 Re: POC: Cleaning up orphaned files using undo logs