Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Tomas Vondra |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | 20190617145247.u24npdpkatk6huvr@development обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
On Mon, Jun 17, 2019 at 10:33:11AM -0400, Stephen Frost wrote: >Greetings, > >* Tomas Vondra (tomas.vondra@2ndquadrant.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
В списке pgsql-hackers по дате отправления: