Re: Proposed patch for key managment

Greetings,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Wed, Dec 30, 2020 at 06:49:34PM -0500, Stephen Frost wrote:
> > The API to fetch the KEK doesn't care at all about where it's stored or
> > how it's derived or anything like that. There's a relatively small
> > change which could be made to have PG request all of the keys that it'll
> > need on startup, if we want to go there as has been suggested elsewhere,
> > but even if we do that, PG needs to be able to do that itself too,
> > otherwise it's not a complete capability and there seems little point in
> > doing something that's just a pass-thru to something else and isn't able
> > to really be used.
>
> Right now, the script returns a cluster key (KEK), and during initdb the
> server generates data encryption keys and wraps them with the KEK.
> During server start, the server validates the KEK and decrypts the data
> keys. pg_alterckey allows changing the KEK.

Right- all of those are really necessary things for PG to have a useful
implementation.

> I think Fabien is saying this all should _only_ be done using external
> tools --- that's what I don't agree with.

I also don't agree that everything should be external. We effectively
have that today and it certainly doesn't get us any closer to having a
solution in PG, a point which we are frequently pointed to as a reason
why certain, entirely reasonable, use-cases can't be satisfied with PG.

Thanks,

Stephen