In set-principal-key.md:
* updated with correct code example using set_server_key_using_global
parameter
* updated note to reflect correct config
In features.md:
* Removed temporary tables feature to clear confusion, removed logical
replication mention, removed WAL encryption as a feature.
In functions.md:
* Added ON FUNCTION for grant/revoke execution
* Modified sensitive info bolded paragraph to important note
* Small modifications to notes display, title cases and text fixes
* added note to Add or modify Vault providers for keeping the same
principal key.
* Added warning for WAL in pg_tde_create_key_using_global_key_provider
In general:
* Removed all logical replication mentions except the FAQ and in RC2
release note.
@ -8,15 +8,15 @@ By default, `pg_tde` is locked down. No one is allowed to do any operations unti
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`
* `REVOKE EXECUTE`
* `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:
* local file (not recommended for production use)
* Hashicorp Vault / OpenBao
* HashiCorp Vault / OpenBao
* KMIP compatible providers
Key provider management includes the following operations:
@ -52,9 +52,11 @@ The `change` functions require the same parameters as the `add` functions. They
Provider specific parameters differ for each implementation. Refer to the respective subsection for details.
**Some provider specific parameters contain sensitive information, such as passwords. Never specify these directly, use the remote configuration option instead.**
!!! note
The updated provider must be able to retrieve the same principal keys as the original configuration.
If the new configuration cannot access existing keys, encrypted data and backups will become unreadable.
#### Adding or modifying Vault providers
#### Add or modify Vault providers
The Vault provider connects to a HashiCorp Vault or an OpenBao server, and stores the keys on a key-value store version 2.
@ -106,7 +108,7 @@ where:
* `secret_token_path` is a path to the file that contains an access token with read and write access to the above mount point
* **[optional]** `ca_path` is the path of the CA file used for SSL verification
#### Adding or modifying KMIP providers
#### Add or modify KMIP providers
The KMIP provider uses a remote KMIP server.
@ -165,16 +167,16 @@ where:
!!! note
The specified access parameters require permission to read and write keys at the server.
### Adding or modifying local keyfile providers
### Add or modify local keyfile providers
This provider manages database keys using a local keyfile.
This provider manages database keys using a local keyfile.
This function is intended for development or quick testing, and stores the keys unencrypted in the specified data file.
!!! important
Local keyfile providers are **not recommended** for production environments, they lack the security and manageability of external key management systems.
Local keyfile providers are **not recommended** for production environments, they lack the security and manageability of external key management systems.
@ -225,14 +227,33 @@ These functions list the details of all key providers for the current database o
* `pg_tde_list_all_database_key_providers()`
* `pg_tde_list_all_global_key_providers()`
!!! important
All configuration values include possibly sensitive values, such as passwords. **Never** specify these directly, use the remote configuration option instead.
## Principal key management
Use these functions to create a new principal key for a specific scope such as a current database, a global or default scope. You can also use them to start using a different existing key for a specific scope.
Use these functions to create a new principal key at a given key provider, and to use those keys for a specific scope such as a current database, a global or default scope. You can also use them to start using a different existing key for a specific scope.
Principal keys are stored on key providers by the name specified in this function - for example, when using the Vault provider, after creating a key named "foo", a key named "foo" will be visible on the Vault server at the specified mount point.
Princial keys are stored on key providers by the name specified in this function - for example, when using the Vault provider, after creating a key named "foo", a key named "foo" will be visible on the Vault server at the specified mount point.
Creates a principal key using the database-local key provider with the specified name. Use this key later with [`pg_tde_set_key_using_database_key_provider()`](#pg_tde_set_key_using_database_key_provider).
The WAL encryption feature is currently in beta and is not effective unless explicitly enabled. It is not yet production ready. **Do not enable this feature in production environments**.
=======
The `ensure_new_key` parameter instructs the function how to handle a principal key during key rotation:
If the specified key does **not** exist, a new encryption key is created under the given name. In this case, the key material (actual cryptographic key) is auto-generated by `pg_tde` and stored securely by the configured provider.
!!! note
This process sets the **default principal key** for the server. Any database without its own key configuration will use this key.
This process sets the **default principal key for the entire server**. Any database without a key explicitly configured will fall back to this key.
## Example
This example is for testing purposes only. Replace the key name and provider name with your values:
The `pg_tde` extension is available for [Percona Server for PostgreSQL 17.x](https://docs.percona.com/postgresql/17/postgresql-server.html), an open source, drop-in replacement for PostgreSQL Community. This version provides the `tde_heap` access method and offers [full encryption capabilities](../features.md), including encryption of tables, indexes, WAL data, and support for logical replication.
The `pg_tde` extension is available for [Percona Server for PostgreSQL 17.x](https://docs.percona.com/postgresql/17/postgresql-server.html), an open source, drop-in replacement for PostgreSQL Community. This version provides the `tde_heap` access method and offers [full encryption capabilities](../features.md), including encryption of tables, indexes and WAL data.
The extension is tightly integrated with Percona Server for PostgreSQL to deliver enhanced encryption functionality that is not available in community builds.
@ -8,7 +8,7 @@ The extension is tightly integrated with Percona Server for PostgreSQL to delive
By using our PostgreSQL distribution, you get:
- **Full encryption support** through the `tde_heap` access method, including tables, indexes, WAL data, and logical replication.
- **Full encryption support** through the `tde_heap` access method, including tables, indexes and WAL data.
- **Enhanced performance and enterprise-ready features** not available in community builds.
- **Regular updates and security patches** backed by Percona’s expert support team.
- **Professional support** and guidance for secure PostgreSQL deployments.