Re: pgsql: Add pg_alterckey utility to change the cluster key

On Sun, Dec 27, 2020 at 10:11:17AM +0900, Michael Paquier wrote:
> Hmm. That sounds like a fair concern to me. Based on the information
> given by the docs, three keys are actually created/used at initdb
> time:
> - One for the relation files, that does not have to be shared across
> the nodes in the cluster.
> - One for the WAL files, that has to be shared across the nodes of the
> cluster or no physical replication could happen.
> - One to encrypt the first two ones.
>
> The first two keys are stored in pg_cryptokeys/ in the data directory,
> while the third one is retrieved using a GUC for validation at server
> startup for the other two. Do we necessarily have to store the first
> level keys within the data directory? I guess that this choice has
> been made for performance, but is that really something that a user
> would want all the time? AES256 is the only option available for the
> data keys. What if somebody wants to roll in their own encryption?

To clarify, we encrypt the data keys using AES256, but the data keys
themselves can be 128, 192, or 256 bits.

> Companies can have many requirements in terms of accepting the use of
> one option or another.

I think ultimately we will need three commands to control the keys.
First, there is the cluster_key_command, which we have now. Second, I
think we will need an optional command which returns random bytes ---
this would allow users to get random bytes from a different source than
that used by the server code.

Third, we will probably need a command that returns the data encryption
keys directly, either heap/index or WAL keys, probably based on key
number --- you pass the key number you want, and the command returns the
data key. There would not be a cluster key in this case, but the
command could still prompt the user for perhaps a password to the KMS
server. It could not be used if any of the previous two commands are
used. I assume an HMAC would still be stored in the pg_cryptokeys
directory to check that the right key has been returned.

I thought we should implement the first command, because it will
probably be the most common and easiest to use, and then see what people
want added.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee