Transparent Data Encryption (TDE) v1

Important

TDE is available only for operands that support it: EPAS versions 15 and newer.

Transparent Data Encryption, or TDE, is a technology used by several database vendors to encrypt data at rest, i.e. database files on disk. TDE does not however encrypt data in use.

TDE is included in EDB Postgres Advanced Server (EPAS), starting with version 15, and it is supported by the EDB Postgres for Kubernetes operator.

Important

Before you proceed, please take some time to familiarize with the TDE feature in the EPAS documentation.

With TDE activated, both WAL files and files for tables will be encrypted. Data encryption/decryption is entirely transparent to the user, as it is managed by the database without requiring any application changes or updated client drivers.

EDB Postgres for Kubernetes provides 3 ways to use TDE:

  • using a secret containing the passphrase
  • using a secret containing a custom passphrase command
  • using a pair of secrets containing custom wrap/unwrap commands

Passphrase secret

The basic approach is to store the passphrase in a Kubernetes secret. Such a passphrase will be used to encrypt the EPAS binary key.

EPAS documentation

Please refer to the EPAS documentation for details on the EPAS encryption key.

Activating TDE on the operator is simple. In the epas section of the manifest, use the tde stanza to enable TDE, and set the Kubernetes secret that will hold the TDE encryption key.

For example:

  []
  postgresql:
    epas:
      tde:
        enabled: true
        secretKeyRef:
          name: tde-key
          key: key

You can find an example in cluster-example-tde.yaml.

Note

This file also contains the definition of the secret to hold the encryption key. Look at the following section for an example on how to create a secret for this purpose.

The key stored in the secret will be used as the pass-phrase to invoke openssl to wrap/unwrap the EPAS encryption key.

How to create the secret containing the passphrase

First choose the passphrase. While it is recommended to use a randomly generated passphrase, in this example we will use PostgresRocks as passphrase, and rely on kubectl to generate for us the secret definition:

kubectl create secret generic -o yaml tde-key \
    --from-literal=key=PostgresRocks

This should return something like this:

apiVersion: v1
data:
  key: UG9zdGdyZXNSb2Nrcw==
kind: Secret
metadata:
  creationTimestamp: "YYYY-MM-DDTHH:MM:SSZ"
  name: tde-key
  namespace: default
  resourceVersion: ....
  uid: ....
type: Opaque

Remember to run kubectl apply or remove the -o yaml option to the create command above to actually create the secret in the cluster.

Custom passphrase command

Instead of the secretKeyRef in the cluster manifest snippet above, it is possible to specify a passphraseCommand stored in a secret. The passphrase command can be run to generate a passphrase to be used with openssl.

  []
  postgresql:
    epas:
      tde:
        enabled: true
        passphraseCommand:
          name: tde-passphrase
          key: command

The passphrase command should write to standard output. For example, we could simply use echo my-passphrase.

The passphrase generated by the command will be used the same way the secretKeyRef was used, i.e. as a passphrase argument for openssl.

Custom wrap/unwrap commands

It is also possible to specify the wrap and unwrap commands, rather than rely on the default invocation of openssl. This can be done by creating secrets containing the custom commands, and declaring those secrets in the tde stanza.

The snippet below shows a cluster with TDE enabled using custom commands.

  []
  postgresql:
    epas:
      tde:
        enabled: true
        wrapCommand:
          name: tde-wrap-command
          key: command
        unwrapCommand:
          name: tde-unwrap-command
          key: command

The custom commands need to obey the following conventions:

  1. The custom wrap command should accept input from standard input, which EPAS will use to feed it the binary key. It should write to a file via an explicit argument (not shell redirections). Moreover, the file argument should be given the string "%p", which is a placeholder EPAS will use to pass the file path of the new, wrapped encryption key file.

  2. The custom unwrap command should write to standard output. It should have an explicit file path argument for input (not shell redirections). Again, the file argument should be given the string "%p", which is the placeholder EPAS will fill in with the wrapped encryption key file path.

For example:

  • wrap command: openssl enc -aes-128-cbc -pass pass:temp-pass -e -out %p
  • unwrap command: openssl enc -aes-128-cbc -pass pass:temp-pass -d -in %p