Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 01:44:51PM -0400, Stephen Frost wrote: > > Just to be clear, I don't have any issue with discussing the idea that > > we want to get to a point where we can work with multiple keys and > > encrypt different tables with different keys (or not encrypt certain > > tables, et al) with the goal of implementing the single-key approach in > > a way that allows us to expand on it down the road easily, I just don't > > think we need to have it all done in the very first patch which adds the > > ability to encrypt the data files. Maybe you're not saying that it has > > to be included in the first implementation, in which case we seem to > > just be talking past each other, but that isn't the impression I got.. > > We don't want to implement all-cluster encryption with a simple user API > and then realize we need another API for later encryption features, do > we?
I actually suspect that's exactly where we'll end up- but due to necessity rather than because there's a way to avoid it. We are going to want to encrypt cluster-wide components of the system (shared catalogs, WAL, etc) and that means that we have to have a key provided very early on. That's a very different thing from being able to do something like encrypt specific tables, tablespaces, etc, where the key can be provided much later and we'll want to allow users to use SQL or the libpq protocol to be able to specify what to encrypt and possibly even provide the encryption keys. That said, the approach outlined here could be used for both by expanding on the command string, perhaps passing it a keyid which is what we store in the catalog to indicate what key a table is encrypted with and then the keyid is "%k" in the command string and the command has to return the specified key for us to decrypt the table. That would involve adding a new catalog table to identify keys and their keyids, I'd think, and an additional column in pg_class which specifies the key (or perhaps we'd just have a new catalog table that says what tables are encrypted in what way). Thanks! Stephen
signature.asc
Description: Digital signature