Horton

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

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Joe Conway <mail@joeconway.com>, Antonin Houska <ah@cybertec.at>, Stephen Frost <sfrost@snowman.net>, Masahiko Sawada <sawada.mshk@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Haribabu Kommi <kommi.haribabu@gmail.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-15T23:39:20Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revamp the WAL record format.

On 2019-Jul-15, Bruce Momjian wrote:

> My point is that doing encryption of only some data might actually make
> the system slower due to the lookups, so I think we need to implement
> all-cluster encryption and then see what the overhead is, and if there
> are use-cases for not encrypting only some data.

We can keep the keys in the relcache.  It doesn't have to be slow.  It
is certainly slower to have to encrypt *all* data, which can be
massively larger than the sensitive portion of the database.

If we need the keys for offline operation (where relcache is not
reachable), we can keep pointers to the key files in the filesystem --
for example for an encrypted table we would keep a new file, say
<relfilenode>.key, which could be a symlink to the encrypted key file.
The tool already has access to the key data, but the symlink lets it
know *which* key to use; random onlookers cannot get the key data
because the file is encrypted with the master key.

Any table without the key file is assumed to be unencrypted.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services