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

On Mon, Jul 08, 2019 at 12:09:58PM -0400, Joe Conway wrote:
>On 7/8/19 11:56 AM, Peter Eisentraut wrote:
>> On 2019-07-08 17:47, Stephen Frost wrote:
>>> Of course, we can discuss if what websites do with over-the-wire
>>> encryption is sensible to compare to what we want to do in PG for
>>> data-at-rest, but then we shouldn't be talking about what websites do,
>>> it'd make more sense to look at other data-at-rest encryption systems
>>> and consider what they're doing.
>>
>> So, how do encrypted file systems do it? Are there any encrypted file
>> systems in general use that allow encrypting only some files or
>> encrypting different parts of the file system with different keys, or
>> any of those other granular approaches being discussed?
>
>Well it is fairly common, for good reason IMHO, to encrypt some mount
>points and not others on a system. In my mind, and in practice to a
>large extent, a postgres tablespace == a unique mount point.
>
>There is a description here:
>
> https://wiki.archlinux.org/index.php/Disk_encryption
>

That link is a bit overwhelming, as it explains how various encrypted
filesystems do things. There's now official support for this in the
Linux kernel (encryption at the filesystem level, not block device) in
the form of fscrypt, see

https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html

It's a bit different because that's not a stacked encryption, it's
integrated directly into filesystems (like ext4, at the moment) and it
leverages other kernel facilities (like keyring).

The link also discusses the threat model, which is interesting
particularly interesting for this discussion, IMO.

regards

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