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.