Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WAL keyring improvements #238

Merged
merged 12 commits into from
Jul 30, 2024
Merged

WAL keyring improvements #238

merged 12 commits into from
Jul 30, 2024

Conversation

dAdAbird
Copy link
Member

@dAdAbird dAdAbird commented Jul 10, 2024

  • Rename database key rotation functions to make room for the global space ones.
  • Now, during the first start, we would create a default temporary key provider for the global space. A user can (and should) create their own key provider afterwards. This allows use the same codepath and internal interfaces for the keyring management across databases and the global space.
  • Now need to cache the principal key for the global space as we use it only at the server start to decrypt internal key. Then internal key persists in the memory cache.

Fixes https://perconadev.atlassian.net/browse/PG-835, https://perconadev.atlassian.net/browse/PG-833

README.md Outdated
@@ -65,15 +65,15 @@ FUNCTION pg_tde_add_key_provider_file(
SELECT pg_tde_add_key_provider_file('file','/tmp/pgkeyring');
```
**Note: The `File` provided is intended for development and stores the keys unencrypted in the specified data file.**
6. Set the principal key for the database using the `pg_tde_set_principal_key` function.
6. Set the principal key for the database using the `pg_tde_set_database_key` function.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now actually looking at this change, I don't think this is a good idea. We just agreed to name "master key" to "principal key" in the beta, and then we would rename all public occurrences again to "database key". Documentation / internal code would still say principal key, but the functions that actually deal with the keys would all be using the database key name.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I had the same thoughts tbh. Should we have pg_tde_set_principal_db_key/ pg_tde_set_principal_global_space_key etc. instead?
The renaming is a one part and the other is creating respective functions for global spaces. But then something like pg_tde_set_principal_global_space_key becomes ridiculously long. Having just ...principal_global_key (w/o space) looks a bit confusing. And I'm starting to consider having pg_tde_set_principal_key() with the enum option DATABASE, GLOBAL_SPACE. But I'm not sure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On another note, not related to this commit, but it might be a right time to do something about that:
Looking at pg_tde--1.0.sql we have inconsistency with the functions naming there. Most time they are prefixed with pg_tde_ but there are pg_tdeam_handler, pg_td2eam_handler, and pgtde_is_encrypted which don't follow that convention

@dAdAbird dAdAbird force-pushed the xlog_keyring branch 4 times, most recently from 672d012 to be3c77f Compare July 16, 2024 15:37
@dAdAbird dAdAbird marked this pull request as ready for review July 18, 2024 13:52
@@ -33,43 +33,43 @@ where:

All parameters can be either strings, or JSON objects [referencing remote parameters](external-parameters.md).

## pg_tde_set_principal_key
## pg_tde_set_database_key
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

database_principal_key?


```sql
SELECT pg_tde_set_principal_key('name-of-the-principal-key', 'provider-name');
SELECT pg_tde_set_database_key('name-of-the-principal-key', 'provider-name');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here

ensure_new_key = PG_GETARG_BOOL(2);


ereport(LOG, (errmsg("Rotating principal key to [%s : %s] for the database", new_principal_key_name, new_provider_name)));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for the cluster, or maybe explicitly mention global key?

@@ -499,7 +511,23 @@ get_keyring_infofile_path(char* resPath, Oid dbOid, Oid spcOid)
}

Datum
pg_tde_add_key_provider_internal(PG_FUNCTION_ARGS)
pg_tde_add_database_key_provider_internal(PG_FUNCTION_ARGS)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could avoid all this code duplication with a simple helper function, only 1 line is different in the two variants.

@dAdAbird dAdAbird force-pushed the xlog_keyring branch 2 times, most recently from 68189fe to a5378e8 Compare July 24, 2024 17:34
Oid dbOid = MyDatabaseId;
Oid spcOid = MyDatabaseTableSpace;

#ifdef PERCONA_FORK
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need this ifdef here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, you're right, we can get rid of it: cf02b52


#ifdef PERCONA_FORK
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question, do we need this ifdef?

Copy link
Collaborator

@dutow dutow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, please make sure to use squash and merge, so we don't get this long commit history into the main branch.

@dAdAbird dAdAbird merged commit 02cd531 into Percona-Lab:main Jul 30, 2024
10 checks passed
@dAdAbird dAdAbird deleted the xlog_keyring branch July 30, 2024 11:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants