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.
I think Fabien is saying this all should _only_ be done using external
tools --- that's what I don't agree with.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
