Percona’s pg_tde project brings a long-needed ability to encrypt data to PostgreSQL transparently. We are actively asking you to test this code to help build a better project. So please test pg_tde!
As you have probably read in earlier blogs on pg_tde, it depends on a keyring.
Two keys
Encrypting the data requires two types of keys.
The first type is the database keys to encrypt user data. These are stored internally, near the data that they encrypt. The second is a master key used to encrypt the database keys. It is kept separately from the database keys and is managed externally.
Two configuration choices
For simple testing, you can use a local key file. But pg_tde works with the HashiCorp Vault server, which will add an extra layer of security to the data if someone somehow gains access to the PostgreSQL server.
Local keyfile
The first choice is to use a local file for the key file. It will look something like the one below. I named my keyring.json and stored it in /etc/postgresql/16/main. Please refer here for examples of using pg_tde on Ubuntu.
1 2 3 4 | { 'provider': 'file', 'datafile': '/tmp/pgkeyring', } |
Do not forget to add a line to your postgresql.conf so the extension knows where its key file is located.
1 | pg_tde.keyringConfigfile = ‘/etc/postgresql/16/main/keyring.json |
HashiCorp Vault
The second option is to use pg_tde with the HashiCorp Vault server to store and manage master keys. Only the back-end KV Secrets Engine – Version two (API) is supported.
The key file will look like this:
1 2 3 4 5 6 7 | { 'provider': 'vault-v2', 'token': 'ROOT_TOKEN', 'url': 'http://127.0.0.1:8200', 'mountPath': 'secret' 'caPath': '<path/to/caFile>' } |
You will need to designate the URL of your Vault server. You will also have to provide a location for the keys as the mountPath. The optional caPath variable is to be used with certificates of authority.
Please test
We are begging you to test pg_tde. Let Percona know your experiences – good, bad, or indifferent.
And please visit the pg_tde forum.
