On Tue, 24 Mar 2020 at 23:15, Bruce Momjian <br...@momjian.us> wrote: > > On Tue, Mar 24, 2020 at 02:29:57PM +0900, Masahiko Sawada wrote: > > That seems to work fine. > > > > So we will have pg_cryptokeys within PGDATA and each key is stored > > into separate file named the key id such as "sql", "tde-wal" and > > "tde-block". I'll update the patch and post. > > Yes, that makes sense to me. >
I've attached the updated patch. With the patch, we have three internal keys: SQL key, TDE-block key and TDE-wal key. Only SQL key can be used so far to wrap and unwrap user secret via pg_wrap and pg_unwrap SQL functions. Each keys is saved to the single file located at pg_cryptokeys. After initdb with enabling key manager, the pg_cryptokeys directory has the following files: $ ll data/pg_cryptokeys total 12K -rw------- 1 masahiko staff 132 Mar 25 15:45 0000 -rw------- 1 masahiko staff 132 Mar 25 15:45 0001 -rw------- 1 masahiko staff 132 Mar 25 15:45 0002 I used the integer id rather than string id to make the code simple. When cluster passphrase rotation, we update all keys atomically using temporary directory as follows: 1. Derive the new passphrase 2. Wrap all internal keys with the new passphrase 3. Save all internal keys to the temp directory 4. Remove the original directory, pg_cryptokeys 5. Rename the temp directory to pg_cryptokeys In case of failure during rotation, pg_cyrptokeys and pg_cyrptokeys_tmp can be left in an incomplete state. We recover it by checking if the temporary directory exists and the wrapped keys in the temporary directory are valid. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
kms_v9.patch
Description: Binary data