PG_TDE is an experimental transparent data encryption access method for PostgreSQL 16 and beyond that I reviewed last October. There have been a lot of changes that covered in this post. This software is under active development. In the spirit of open and transparent communication, we would appreciate your feedback and invite PostgreSQL users to test the extension and provide feedback via the GitHub repository or in the forum.
We need your help
Transparent Data Encryption (TDE) offers encryption at the file level and solves the problem of protecting data at rest. This capability is available in other databases but not provided in upstream, vanilla Postgres.
Percona has received user feedback that this would be a feature, so we are working on this as an open-source extension for Postgres that anyone can deploy. Percona co-founder Peter Zaitsev’s blog on why PostgreSQL needs TDE highlights the technical and business reasons why you might want TDE. Since PostgreSQL doesn’t have TDE features yet, Percona will provide the TDE feature as an extension to PostgreSQL.
But we need your help. Transparent Data Encryption is a complex environment that needs extensive testing. Please download PG_TDE to a test machine, test the PG_TDE, and let us know your experience – good, bad, or indifferent. Percona would like this code hammered as hard as possible to ensure it is robust and ready to become part of a future version of PostgreSQL. Please test.
What Is New
My earlier post on my first experience with pg_tde can be found HERE. The good news is that it worked. I was able to get a Docker environment running very easily, but getting it running on Ubuntu directly took some effort.
My colleague Zslot Parragi wrote an interesting blog Using the Transparent Data Encryption Extension PG_TDE With PostgreSQL that details how the data is encrypted and how to use hexdump to examine that data to make sure that it is encrypted
“But it’s also important to note that not everything in the tuple structure is encrypted: only the actual tuple data gets encrypted, and the tuple headers remain unencrypted. As these fields do not contain sensitive data, this is not a security issue and helps with the performance and simplicity of the extension. Our PG_TDE implementation is based on the original heap engine of PostgreSQL, with as few modifications as possible to encrypt the contents of the tables.”
For those looking for the ‘nitty-gritty’ details on the encryption process and key handling, please refer to that blog post.
Is it encrypted or not?
I expressed my concerns to the engineering team about a lack of a way to ensure the data was encrypted without making a hexadecimal dump. We can now use pgtde_is_encrypted(<table name>). To reply with a ‘t’ or ‘f’ to report the encryption status.
1 2 3 4 5 6 7 8 9 10 11 | tde2=# select pgtde_is_encrypted('test_basic'); pgtde_is_encrypted -------------------- f (1 row) tde2=# select pgtde_is_encrypted('foo_enc'); pgtde_is_encrypted -------------------- t (1 row) |
More To Read
Two companion blogs go along with this one. The first blog covers using PG_TDE in a Docker environment, which is probably the easiest way to investigate transparent data encryption—the second details how to install PG_TDE on Unbuntu 22.04 LTS.
Please test
Percona is committed to delivering PG_TDE, but we need your help. The more instances of this software running and from which we get feedback, the better the product will be. This is your chance to help drive PostgreSQL forward by hammering on this code as hard as possible. This will also help keep you from being an ‘edge case’ where some obscure problem delays your ability to protect your data.
