Skip to content

Commit cb3f515

Browse files
Merge pull request #6354 from EnterpriseDB/release/2024-12-17a
Release: 2024-12-17a
2 parents a0dbcf8 + 81d6a07 commit cb3f515

File tree

5 files changed

+105
-1
lines changed

5 files changed

+105
-1
lines changed

product_docs/docs/pgd/5.6/upgrades/upgrade_paths.mdx

+3
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,9 @@ title: Supported PGD upgrade paths
44

55
## Upgrading within version 5
66

7+
EDB Postgres Distributed uses [semantic versioning](https://semver.org/).
8+
All changes within the same major version are backward compatible, lowering the risk when upgrading and allowing you to choose any later minor or patch release as the upgrade target.
9+
710
You can upgrade from any version 5.x release to a later 5.x release.
811

912
## Upgrading from version 4 to version 5
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
---
2+
title: "Protect the data encryption key on an existing TDE cluster"
3+
description: Learn how to enable a mechanism to protect the data encryption key on an existing TDE-enabled database cluster.
4+
---
5+
6+
If you want to enable key wrapping on TDE-enabled database clusters where key wrapping was previously disabled, update the encryption settings in the `postgresql.conf` file.
7+
8+
## Context
9+
10+
When you create a TDE-enabled database cluster, `initdb` generates a data encryption key and stores it in `pg_encryption/key.bin`. Since this file is stored in plaintext, TDE requires an additional mechanism to [secure the data encryption key](../secure_key/). You normally configure the protection of the key as you initialize your TDE-enabled database cluster.
11+
12+
However, you can chose to [disable key wrapping](../secure_key/disabling_key) for your data encryption key. Although this setup is not recommended, you might have chosen to leave your key unprotected to facilitate managing the cluster for testing or demo purposes.
13+
14+
If you disabled key wrapping, but later decide to enable a mechanism that secures your encryption key, you can enable it at a later time, by updating the encryption settings in the `postgresql.conf` file.
15+
16+
## Enable key wrapping with a passphrase
17+
18+
This example walks you through adding a passphrase-based protection mechanism or key wrapping to your data encryption key (`key.bin`).
19+
20+
1. Store the passphrase in a file accessible by initdb named `pass.bin`:
21+
22+
!!!important
23+
This example stores the passphrase in plaintext, a method you should only use for testing or demonstration purposes. In production environments, don't store your passphrase in a file. See [Using a passphrase](../secure_key/passphrase) for alternative methods.
24+
!!!
25+
26+
```
27+
echo "<passphrase>" > /var/lib/postgresql/pass.bin
28+
```
29+
30+
1. Use OpenSSL to encrypt the existing `key.bin` data encryption key with the stored passphrase and save the encrypted file as `key.bin.WRAP`:
31+
32+
```
33+
cat $PGDATA/pg_encryption/key.bin | openssl enc -e -aes-128-cbc -pbkdf2 -pass file:/var/lib/postgresql/pass.bin -out $PGDATA/pg_encryption/key.bin.WRAP
34+
```
35+
36+
1. Create a backup of the unwrapped data encryption key named `key.bin.NOWRAP` in case you need to roll back to the original configuration:
37+
38+
```
39+
cp $PGDATA/pg_encryption/key.bin $PGDATA/pg_encryption/key.bin.NOWRAP
40+
```
41+
42+
1. Replace the existing data encryption key with the wrapped version:
43+
44+
```
45+
cp $PGDATA/pg_encryption/key.bin.WRAP $PGDATA/pg_encryption/key.bin
46+
```
47+
48+
1. Create a backup of the existing configuration file named `postgresql.conf.NOWRAP` in case you need to roll back to the original configuration:
49+
50+
```
51+
cp $PGDATA/postgresql.conf $PGDATA/postgresql.conf.NOWRAP
52+
```
53+
54+
1. Modify the `data_encryption_key_unwrap_command` value of the `postgresql.conf` file with the new command:
55+
56+
```
57+
sed -i "s|data_encryption_key_unwrap_command.*|data_encryption_key_unwrap_command = 'openssl enc -d -aes-128-cbc -pbkdf2 -pass file:/var/lib/postgresql/pass.bin -in \"%p\"'|" $PGDATA/postgresql.conf
58+
```
59+
60+
1. Create a backup of the modified `postgresql.conf` file that includes the key wrapping named `postgresql.conf.WRAP`:
61+
62+
```
63+
cp $PGDATA/postgresql.conf $PGDATA/postgresql.conf.WRAP
64+
```
65+
66+
1. Restart your database cluster to populate the updated data encryption key configuration:
67+
68+
```
69+
pg_ctl start
70+
```

product_docs/docs/tde/15/enabling/index.mdx

+3
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,9 @@ indexCards: simple
55
navigation:
66
- enabling_tde
77
- enabling_tde_epas
8+
- postgres_to_extended
9+
- enabling_key_wrapper
10+
- verifying_tde
811
---
912

1013
Create a TDE-enabled database server using `initdb`.

product_docs/docs/tde/15/secure_key/disabling_key.mdx

+4
Original file line numberDiff line numberDiff line change
@@ -13,3 +13,7 @@ If you don't want key wrapping, for example, for testing purposes, you can use e
1313
With either one of the configurations, TDE generates encryption key files, but leaves them unprotected.
1414

1515
For `intidb --data-encryption` to run successfully, you have to either specify a wrapping/unwrapping command, set a fallback environment variable with wrapping/unwrapping commands, or disable key wrapping with the one of the previous mechanisms. Otherwise, the creation of an encrypted database cluster will fail.
16+
17+
!!!note
18+
If you want to enable key wrapping on TDE-enabled database clusters where key wrapping was previously disabled, see [Enabling a mechanism to protect the data encryption key](../enabling/enabling_key_wrapper).
19+
!!!

product_docs/docs/tde/15/secure_key/passphrase.mdx

+25-1
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,8 @@ The key wrap command receives the plaintext key on standard input and needs to p
1919

2020
Utility programs like pg_rewind and pg_upgrade operate directly on the data directory or copies, such as backups. These programs also need to be told about the key unwrap command, depending on the circumstances. They each have command line options for this purpose.
2121

22+
## Using environment variables to set wrap and unwrap commands
23+
2224
To simplify operations, you can also set the key wrap and unwrap commands in environment variables. These are accepted by all affected applications if you don't provide the corresponding command line options. For example:
2325

2426
```shell
@@ -40,4 +42,26 @@ You also need an entry like in `/etc/sudoers`:
4042

4143
```
4244
postgres ALL = NOPASSWD: /usr/bin/systemd-ask-password
43-
```
45+
```
46+
47+
## Providing the passphrase through a file
48+
49+
Another way to simplify operations is to store the passphrase in plaintext, so you can reference the file containing the passphrase when securing the data encryption files.
50+
51+
!!!important
52+
You should only use this method for testing or demonstration purposes. Don't store your passphrase in a plaintext file for production environments.
53+
!!!
54+
55+
1. Store the passphrase in a file accessible by initdb named `pass.bin`:
56+
57+
```
58+
echo "<passphrase>" > /var/lib/postgresql/pass.bin
59+
```
60+
61+
1. Reference the file that contains the passphrase when initializing the TDE-enabled database cluster using the `-pass file:<path_to_file>` flag:
62+
63+
```
64+
initdb --data-encryption \
65+
--key-wrap-command='openssl enc -e -aes-128-cbc -pbkdf2 -pass file:/var/lib/postgresql/pass.bin -out "%p"' \
66+
--key-unwrap-command='openssl enc -d -aes-128-cbc -pbkdf2 -pass file:/var/lib/postgresql/pass.bin -in "%p"'
67+
```

0 commit comments

Comments
 (0)