Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
От | Antonin Houska |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Дата | |
Msg-id | 61852.1565861086@antos обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
|
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> wrote: > On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote: > > I can work on it right away but don't know where to start. > > I think the big open question is whether there will be acceptance of an > all-cluster encyption feature. I guess if no one objects, we can move > forward. > > > First, I think we should use a code repository to integrate [1] and [2] > > instead of sending diffs back and forth. That would force us to resolve > > conflicts soon and help to avoid duplicate work. The diffs would be created > > only whe we need to post the next patch version to pgsql-hackers for review, > > otherwise the discussions of details can take place elsewhere. > > Well, we can do that, or just follow the TODO list and apply items as we > complete them. We have found that doing everything in one big patch is > just too hard to review and get accepted. > > > The most difficult problem I see now regarding the collaboration is agreement > > on the key management user interface. The Full-Cluster Encryption feature [1] > > should not add configuration variables or even tools that the next, more > > sophisticated version [2] deprecates immediately. Part of the problem is that > > Yes, the all-cluster encryption feature has _no_ SQL-level API to > control it, just a GUC variable that you can use SHOW to see the > encryption mode. > > > [2] puts all (key management related) interaction of postgres with the > > environment into an external library. As I pointed out in my response to [2], > > this will not work for frontend applications (e.g. pg_waldump). I think the > > key management UI for [2] needs to be designed first even if PG 13 should > > adopt only [1]. > > I think there are several directions we can go after all-cluster > encryption, I think I misunderstood. What you summarize in https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#TODO_for_Full-Cluster_Encryption does include https://www.postgresql.org/message-id/CAD21AoBjrbxvaMpTApX1cEsO=8N=nc2xVZPB0d9e-VjJ=YaRnw@mail.gmail.com i.e. per-tablespace keys, right? Then the collaboration should be easier than I thought. -- Antonin Houska Web: https://www.cybertec-postgresql.com
В списке pgsql-hackers по дате отправления: