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

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, 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:52:47
Message-ID: 20190617145247.u24npdpkatk6huvr@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 17, 2019 at 10:33:11AM -0400, Stephen Frost wrote:
>Greetings,
>
>* Tomas Vondra (tomas(dot)vondra(at)2ndquadrant(dot)com) wrote:
>> In any case, if we end up with a more complex/advanced design, I've
>> already voiced my opinion that binding the keys to tablespaces is the
>> wrong abstraction, and I think we'll regret it eventually. For example,
>> why have we invented publications instead of using tablespaces?
>
>I would certainly hope that we don't stop at tablespaces, they just seem
>like a much simpler piece to bite off piece than going to table-level
>right off, and they make sense for some environments where there's a
>relatively small number of levels of separation, which are already being
>segregated into different filesystems (or at least directories) for the
>same reason that you want different encryption keys.
>

Why not to use the right abstraction from the beginning? I already
mentioned publications, which I think we can use as an inspiration. So
it's not like this would be a major design task, IMHO.

In my experience it's pretty difficult to change abstractions the design
is based on, not just because it tends to be invasive implementation-wise,
but also because users get used to it.

FWIW this is one of the reasons why I advocate for v1 not to allow this,
because it's much easier to extend the design

single group -> multiple groups

compared to

one way to group objects -> different way to group objects

regards

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-06-17 14:56:00 how to run encoding-dependent tests by default
Previous Message Ian Barwick 2019-06-17 14:51:38 Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions