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

On Sat, Dec 26, 2020 at 06:03:00AM -0400, Fabien COELHO wrote:
> The feeling I expressed early in the thread is that the design should be
> extendable, so that it does not fit only one particular use-case but fail at
> any other that were not the author's, and a large reimplementation would be
> needed to get them in. I was thinking of having a closer look with that in
> mind. In particular and IMHO, the "master key" should not (necessarily) be
> hold by a postgres process, not sure what the current status is, but that is
> an example.

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?
Companies can have many requirements in terms of accepting the use of
one option or another.
--
Michael