Greetings, * Bruce Momjian (br...@momjian.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
signature.asc
Description: PGP signature