Encryption in CockroachDB

This page offers an overview of CockroachDB's encryption features.

Encryption in flight

CockroachDB uses either TLS 1.2 or TLS 1.3 for inter-node and client-node authentication as well as setting up a secure communication channel. Once the secure channel is set up, all inter-node and client-node network communication is encrypted using a shared encryption key as per the TLS 1.2 protocol. This feature is enabled by default for all secure clusters and needs no additional configuration.

Encryption at rest

Industry standard encryption-at-rest provided at the infrastructure level by your chosen infrastructure-as-a-service (IAAS) provider, either Google Cloud Platform (GCP) or Amazon Web Services (AWS). See documentation for GCP persistent disk encryption or AWS Elastic Block Storage.

In the context of CockroachDB Cloud, we rely on the cloud provider's encryption-at-rest, and do not enable CockroachDB's Encryption at Rest Enterprise feature (see below).

In the context of CockroachDB Self-Hosted, customers are responsible for managing their own encryption at rest. Usage of recommended IAAS providers such as GCP and AWS includes the encryption at rest services they offer by default.

In both of the above contexts, encryption will appear to be disabled in the DB Console, as it there refers to the Encryption at Rest (Enterprise) feature.

Encryption at Rest (Enterprise)

CockroachDB's Encryption at Rest (Enterprise) feature provides transparent encryption of a node's data on the local disk. It allows encryption of all files on disk using AES in counter mode, with all key sizes allowed.

Encryption is performed in the storage layer and configured per store. All files used by the store, regardless of contents, are encrypted with the desired algorithm.

To allow arbitrary rotation schedules and ensure security of the keys, we use two layers of keys:

  • Store keys are provided by the user in a file. They are used to encrypt the list of data keys (see below). This is known as a key encryption key: its only purpose is to encrypt other keys. Store keys are never persisted by CockroachDB. Since very little data is encrypted using this key, it can have a very long lifetime without risk of reuse.

  • Data keys are automatically generated by CockroachDB. They are used to encrypt all files on disk. This is known as a data encryption key. Data keys are persisted in a key registry file, encrypted using the store key. The key has a short lifetime to avoid reuse.

Store keys are specified at node startup by passing a path to a locally readable file. The file must contain 32 bytes (the key ID) followed by the key (16, 24, or 32 bytes). The size of the key dictates the version of AES to use (AES-128, AES-192, or AES-256). For an example showing how to create a store key, see Generating key files below.

Also during node startup, CockroachDB uses a data key with the same length as the store key. If encryption has just been enabled, the key size has changed, or the data key is too old (default lifetime is one week), CockroachDB generates a new data key.

Any new file created by the store uses the currently-active data key. All data keys (both active and previous) are stored in a key registry file and encrypted with the active store key.

After startup, if the active data key is too old, CockroachDB generates a new data key and marks it as active, using it for all further encryption.

CockroachDB does not currently force re-encryption of older files but instead relies on normal storage engine churn to slowly rewrite all data with the desired encryption.

Rotating keys

Key rotation is necessary for Encryption at Rest for multiple reasons:

  • To prevent key reuse with the same encryption parameters (after encrypting many files).
  • To reduce the risk of key exposure.

Store keys are specified by the user and must be rotated by specifying different keys. This is done by restarting each node and setting the key parameter of the --enterprise-encryption flag to the path to the new key, and old-key to the previously used key. For an example, see Changing encryption algorithm or keys.

Data keys will automatically be rotated at startup if any of the following conditions are met:

  • The active store key has changed.
  • The encryption type has changed (different key size, or plaintext to/from encryption).
  • The current data key is rotation-period old or more.

Data keys will automatically be rotated at runtime if the current data key is rotation-period old or more.

Once rotated, an old store key cannot be made the active key again.

Upon store key rotation the data keys registry is decrypted using the old key and encrypted with the new key. The newly-generated data key is used to encrypt all new data from this point on.

Changing encryption type

The user can change the encryption type from plaintext to encryption, between different encryption algorithms (using various key sizes), or from encryption to plaintext.

When changing the encryption type to plaintext, the data key registry is no longer encrypted and all previous data keys are readable by anyone. All data on the store is effectively readable.

When changing from plaintext to encryption, it will take some time for all data to eventually be re-written and encrypted.


There are a number of considerations to keep in mind when running with encryption.

Deployment configuration

To prevent key leakage, production deployments should:

  • Use encrypted swap, or disable swap entirely.
  • Disable core files.

CockroachDB attempts to disable core files at startup when encryption is requested, but it may fail.

Key handling

Key management is the most dangerous aspect of encryption. The following rules should be kept in mind:

  • Make sure that only the UNIX user running the cockroach process has access to the keys.
  • Do not store the keys on the same partition/drive as the CockroachDB data. It is best to load keys at run time from a separate system (e.g., Keywhiz, Vault).
  • Rotate store keys frequently (every few weeks to months).
  • Keep the data key rotation period low (default is one week).

Other recommendations

A few other recommendations apply for best security practices:

  • Do not switch from encrypted to plaintext, this leaks data keys. When plaintext is selected, all previously encrypted data must be considered reachable.
  • Do not copy the encrypted files, as the data keys are not easily available.
  • If encryption is desired, start a node with it enabled from the first run, without ever running in plaintext.

Note that backups taken with the BACKUP statement are not encrypted even if Encryption at Rest is enabled. Encryption at Rest only applies to the CockroachDB node's data on the local disk. If you want encrypted backups, you will need to encrypt your backup files using your preferred encryption method.

Encrypted backups (Enterprise)

See Take and Restore Encrypted Backups.

Encryption caveats

Higher CPU utilization

Enabling Encryption at Rest might result in a higher CPU utilization. We estimate a 5-10% increase in CPU utilization.

Encryption for touchpoints with other services

  • S3 backup encryption
  • Encrypted comms with Kafka

See also

Yes No