Transparent Data Encryption (TDE) for AlloyDB Omni

Select a documentation version:

Transparent Data Encryption (TDE) lets you secure all data at rest in your AlloyDB Omni clusters without modifying your application code. By enabling this feature, you ensure that tables, indexes, and write-ahead logs (WAL) are automatically encrypted before being written to disk. This helps you meet compliance requirements and protect sensitive information.

The encryption is transparent because SQL queries, DDL, and DML operations function normally without requiring application changes. Data is automatically encrypted before being written to disk and decrypted when read into memory.

Key hierarchy

AlloyDB Omni implements a two-tier key hierarchy that maintains a strict separation of duties between the database and the user-managed security infrastructure.

  • Data Encryption Keys (DEKs): generated and owned by AlloyDB Omni. These keys encrypt the actual data files, WAL, and temporary files. AlloyDB Omni stores DEKs on disk but wraps them with your KEK.
  • Key Encryption Key (KEK): the main key that you manage in an external Key Management Service (KMS). AlloyDB Omni uses your KEK to encrypt the DEKs. AlloyDB Omni accesses this key only at startup to unwrap the DEKs. Your KEK is never stored persistently on the database disk.
    • The KEK's location and access parameters are defined within the TdeConfig custom resource.

How TDE works with AlloyDB Omni

When TDE is enabled, AlloyDB Omni secures your data using a layered encryption model that integrates with an external KMS.

  • Initialization and key retrieval: during the cluster's startup or initialization phase, the AlloyDB Omni engine establishes a secure connection to your KMS. It authenticates using a JSON Web Token (JWT) and retrieves the KEK.
  • Unwrapping the DEKs: AlloyDB Omni uses your KEK to unwrap the DEKs, which are stored on the local storage in a wrapped state. Then, these DEKs are loaded into memory.
  • Transparent data operations:
    • Writing to disk: as the database writes data blocks, WAL records, or temporary files to the physical disk, it automatically encrypts the data using AES-256 algorithms before it writes to the physical disk.
    • Reading from disk: when the database needs to read data into memory, it automatically decrypts the blocks using the DEKs that are held in memory.
  • Security boundaries: your KEK is never stored on the local database disk, ensuring that even if physical storage media is compromised, the data remains unreadable without authorized access to the external vault.

Encryption scope and specifications

AlloyDB Omni uses industry-standard AES-256 algorithms to secure your data.

  • Data files (tables and indexes): AES-256-XTS.
  • Write-ahead logs (WAL): AES-256-CTR.
  • Temporary files: AES-256-XTS or AES-256-CTR depending on the type of temporary data.
  • Key wrapping: AES-256-KWP.

Backup and high availability

When TDE is enabled, backups created using pgBackRest inherit the encryption configuration of the source cluster. This ensures that your backup data remains protected with the same level of security as your primary database.

You can only restore backups if the `TdeConfig` resource used at the time of taking a backup is available in the same namespace as the target cluster.

For HA setups, the TdeConfig must be present in the namespace as the DbCluster resource.

Supported KMS and authentication

AlloyDB Omni supports HashiCorp Vault as the external KMS provider. AlloyDB Omni only supports KV-V2 secrets engine, and the only supported authentication method is JWT.

PostgreSQL tool compatibility

TDE-enabled clusters support all built-in PostgreSQL tools through the TdeConfig resource.

Limitations

  • You cannot enable TDE on existing clusters.
  • Once enabled, you cannot disable TDE.
  • Major version upgrades are not supported for TDE-enabled clusters.
  • You cannot restore encrypted backups to unencrypted servers or unencrypted backups to encrypted servers.
  • DEK rotation is not supported.
  • KEK rotation is supported as long as the KEK URL path remains the same.
  • You cannot CREATE DATABASE using the FILE_COPY strategy.
  • On TDE-enabled clusters, Barman backups only support rsync mode. The postgres backup method isn't supported.

What's next