On 18/6/20 19:41, Cary Huang wrote:
Hi all
Having read through the discussion, I have some comments and
suggestions that I would like to share.
I think it is still quite early to even talk about external key
management system even if it is running on the same host as PG. This
is most likely achieved as an extension that can provide communication
to external key server and it would be a separate project/discussion.
I think the focus now is to finalize on the internal KMS design, and
we can discuss about how to migrate internally managed keys to the
external when the time is right.
As long as there exists a clean interface, and the "default" (internal)
backend is a provider of said functionality, it'll be fine.
Given that having different KMS within a single instance (e.g. per
database) is quite unlikely, I suggest just exposing hook-like
function-pointer variables and be done with it. Requiring a preloaded
library for this purpose doesn't seem too restrictive ---at least at
this stage--- and can be very easily evolved in the future ---
super-simple API which receives a struct made of function pointers, plus
another function to reset it to "internal defaults" and that's it.
Key management system is generally built to manage the life cycle of
cryptographic keys, so our KMS in my opinion needs to be built with
key life cycle in mind such as:
* Key generation
* key protection
* key storage
* key rotation
* key rewrap
* key disable/enable
* key destroy
Add the support functions for your suggested "key information"
functionality, and that's a very rough first draft of the API ...
KMS should not perform the above life cycle management by itself
automatically or hardcoded, instead it should expose some interfaces
to the end user or even a backend process like TDE to trigger the above.
The only key KMS should manage by itself is the KEK, which is derived
from cluster passphrase value. This is fine in my opinion. This KEK
should exist only within KMS to perform key protection (by wrapping)
and key storage (save as file).
Asking for the "cluster password" is something better left optional /
made easily overrideable ... or we risk thousands of clusters suddenly
not working after a reboot.... :S
Just my .02€
Thanks,
J.L.
