RE: [Proposal] Table-level Transparent Data Encryption (TDE) andKey Management Service (KMS) - Mailing list pgsql-hackers

From Smith, Peter
Subject RE: [Proposal] Table-level Transparent Data Encryption (TDE) andKey Management Service (KMS)
Date
Msg-id 201DD0641B056142AC8C6645EC1B5F62014B8796BB@SYD1217
Whole thread Raw
In response to Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
> -----Original Message-----
> From: Stephen Frost <sfrost@snowman.net> Sent: Friday, 16 August 2019 11:01 AM

> Having direct integration with a KMS would certainly be valuable, and I don't see a reason to deny users that option
ifsomeone would like to spend time 
> implementing it- in addition to a simpler mechanism such as a passphrase command, which I believe is what was being
suggestedhere. 

Yes. We recently made an internal PoC for FEP to enable it to reach out to AWS KMS whenever the MKEY was rotated or
TDKEYwas created. This was achieved by inserting some hooks in our TDE code - these hooks were implemented by a
contrib-moduleloaded by the shared_preload_libraries GUC variable. So when no special "tdekey_aws" module was loaded,
ourTDE functionality simply reverts to its default (random) MDEK/TDEK keys.  

Even if OSS community chooses not to implement any KMS integration, the TDE design could consider providing hooks in a
fewappropriate places to make it easy for people who may need to add their own later. 

Regards,
---
Peter Smith
Fujitsu Australia




pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Resume vacuum and autovacuum from interruption and cancellation
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Patch: New GUC prepared_statement_limit to limit memory usedby prepared statements