Updated the introduction with the proper extension name, updated the
intro to reflect this. Removed important note about not meant for
production and added the No upgrade warning from previous versions (like
RC2) to GA. Updates:
* removed the block announcement for RC2 at the top of the HTML page in
the intro
* Added the warning note before installation begins too.
* Updated site name to full name.
For database specific providers, the function first checks if the provider is used or not, and the provider is only deleted if it's not used.
For global providers, the function checks if the provider is used anywhere, WAL or any specific database, and returns an error if it is.
This somewhat goes against the principle that `pg_tde` should not interact with other databases than the one the user is connected to, but on the other hand, it only does this lookup in the internal `pg_tde` metadata, not in postgres catalogs, so it is a gray zone. Making this check makes more sense than potentially making some databases inaccessible.
### Listing/querying providers
`pg_tde` provides 2 functions to show providers:
@ -263,17 +259,6 @@ This somewhat goes against the principle that `pg_tde` should not interact with
These functions return a list of provider names, type and configuration.
### Provider permissions
`pg_tde` implements access control based on execution rights on the administration functions.
For keys and providers administration, it provides two pair of functions:
```sql
pg_tde_GRANT_database_key_management_TO_role
pg_tde_REVOKE_database_key_management_FROM_role
```
### Creating and rotating keys
Principal keys can be created using the following functions:
@ -325,12 +310,6 @@ The `pg_tde_delete_key()` function unsets the principal key for the current data
`pg_tde_verify_key()` checks that the key provider is accessible, that the current principal key can be downloaded from it, and that it is the same as the current key stored in memory - if any of these fail, it reports an appropriate error.
### Key permissions
Users with management permissions to a specific database `(pg_tde_(grant/revoke)_(global/databse)_key_management_(to/from)_role)` can change the keys for the database, and use the current key functions. This includes creating keys using global providers, if `pg_tde.inherit_global_providers` is enabled.
Also the `pg_tde_(grant/revoke)_database_key_management_to_role` function deals with only the specific permission for the above function: it allows a user to change the key for the database, but not to modify the provider configuration.
### Creating encrypted tables
To create an encrypted table or modify an existing table to be encrypted, use the following commands:
@ -27,7 +27,7 @@ Using TDE helps you avoid the following risks:
If to translate sensitive data to files stored in your database, these are user data in tables, temporary files, WAL files. TDE has you covered encrypting all these files.
`pg_tde` does not encrypt system catalogs yet. This means that statistics data and database metadata are not encrypted. The encryption of system catalogs is planned for future releases.
`pg_tde` does not encrypt system catalogs yet. This means that statistics data and database metadata are not encrypted.
## Will logical replication work with pg_tde?
@ -121,7 +121,9 @@ We advise encrypting the whole database only if all your data is sensitive, like
For WAL encryption, AES-CTR-128 is used.
The support of other encryption mechanisms such as AES256 is planned for future releases. Reach out to us with your requirements and usage scenarios of other encryption methods are needed.
## Is post-quantum encryption supported?
No, it's not yet supported. In our implementation we reply on OpenSSL libraries that don't yet support post-quantum encryption.
The `pg_tde` extension provides functions for managing different aspects of its operation:
## Permission management
By default, `pg_tde` is locked down. No one is allowed to do any operations until you grant them permissions. Only superusers may add or alter global key providers.
However, database owners can run the “view keys” and “set principal key” functions on their own databases. You can delegate these rights to other roles with the following commands:
* `GRANT EXECUTE ON FUNCTION`
* `REVOKE EXECUTE ON FUNCTION`
## Key provider management
A key provider is a system or service responsible for managing encryption keys. `pg_tde` supports the following key providers:
# Percona Transparent Data Encryption for PostgreSQL documentation
`pg_tde` is the open source, community driven and futureproof PostgreSQL extension that provides Transparent Data Encryption (TDE) to protect data at rest. `pg_tde` ensures that the data stored on disk is encrypted, and that no one can read it without the proper encryption keys, even if they gain access to the physical storage media.
Percona Transparent Data Encryption for PostgreSQL (`pg_tde`) is an open source, community driven and futureproof PostgreSQL extension that provides Transparent Data Encryption (TDE) to protect data at rest. `pg_tde` ensures that the data stored on disk is encrypted, and that no one can read it without the proper encryption keys, even if they gain access to the physical storage media.
!!! important
This is the {{release}} version of the extension and **it is not meant for production use yet**. We encourage you to use it in testing environments and [provide your feedback](https://forums.percona.com/c/postgresql/pg-tde-transparent-data-encryption-tde/82).
!!! warning "No upgrade path from RC to GA"
There is no safe upgrade path from the previous versions, such as Release Candidate 2, to the General Availability (GA) version of `pg_tde`.
We recommend starting with a **clean installation** for GA deployments. Avoid using RC environments in production.
Dragos Andriciuc
3 months ago
committed by