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

On Wed, Mar 6, 2019 at 6:32 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Wed, Mar 6, 2019 at 10:49:17AM -0800, Jeremy Schneider wrote:
> > Might it make sense to generalize a little bit to secret management? It
> > would be *great* if PostgreSQL could have a standard "secrets" API which
> > could then use plugins or extensions to provide an internal
> > implementation (software or hardware based) and/or plug in to an
> > external secret management service, whether an OSS package installed on
> > the box or some 3rd party service off the box.
> >
> > The two obvious use cases are encryption keys (mentioned here) and
> > passwords for things like logical replication, FDWs, dblinks, other
> > extensions, etc. Aside from adding new encryption key secrets, the way
> > PostgreSQL handles the existing secrets it already has today leaves room
> > for improvement.
>
> See this email for a possible implementation:
>
> https://www.postgresql.org/message-id/20190222035816.uozqvc4wjyag3pme@momjian.us

I don't think that actually does what would be needed here.
pgcryptokey can manage the keys themselves, but the secrets (i.e.
passwords) that are used to access those keys are and must be revealed
to everyone who uses them. I think we can imagine a
secrets-management solution where that's not the case -- where you can
access an encrypted database cluster or an encrypted table or an
encrypted column or an FDW on another server without being able to
access either the encryption key or the password for that key.

Generally, I think our interest should be less in how secrets are
stored inside the database than in how we can integrate with an
external secrets-management solution, and I think that's what Jeremy
is talking about here. I don't know exactly how that would work, but
you can imagine having a way to tell an FDW "hey, there's a password
for this server, but it's not stored here -- instead go fetch secret
d41d8cd98f00b204e9800998ecf8427e" and the server does that and uses
that password for the connection. But we don't need to solve the FDW
problem for this effort to move forward. We do, however, need a
solution that's good enough for whatever we want to do in terms of
TDE.

If we imagine whole-database TDE, then there's really only one secret,
so there's not much to design. We can just have a command that is
configured via a GUC that has to return the secret, and a user can put
whatever script they like in there. But if we want to have
fine-grained TDE where different bits are encrypted with different
keys, then we have to have a way to request whichever key is needed
for a certain bit of data. I don't know whether it's good enough to
just run a script and pass it some identifier and let it return the
corresponding key, or whether we should try to do something more
ambitious than that in the hopes of meeting more use case. Sometimes
the perfect can be the enemy of the good, but half-baked solutions are
no good either.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company