On Mon, Jun 17, 2019 at 08:29:02AM -0400, Joe Conway wrote:
>On 6/17/19 8:12 AM, Stephen Frost wrote:
>>> But there's about 0% chance we'll get that in v1, of course, so we need
>>> s "minimum viable product" to build on anyway.
>>
>> There seems like a whole lot of space between something very elaborate
>> and only supporting one key.
>
>I think this is exactly the point -- IMHO one key per tablespace is a
>nice and very sensible compromise. I can imagine all kinds of more
>complex things that would be "nice to have" but that gets us most of the
>flexibility needed with minimal additional complexity.
>
Not sure.
I think it's clear the main challenge is encryption of shared resources,
particularly WAL (when each WAL record gets encrypted with the same key as
the object). Considering the importance of WAL, that complicates all sorts
of stuff (recovery, replication, ...).
Encrypting WAL with a single key would be way easier, because we could
(probably) just encrypt whole WAL pages. That may not be appropriate for
some advanced use cases, of course. It would work when used as a db-level
replacement for FDE, which I think was the primary motivation for TDE.
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?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services