Transparent Data Encryption

Transparent Data Encryption (TDE) encrypts data at the engine layer as it is written to storage, so a copy of the files is worthless without the key. The cluster never stores or caches the master key: it asks your key service to wrap and unwrap a key for each file.

This protects data at rest, not data in transit

A client's connection to the cluster is a separate concern, covered by Connect the operator to an SSL-enabled FE. Encrypting one does nothing for the other, and a requirement that names encryption usually means both.

Before you start

TDE is decided when the cluster is created. You cannot enable it on a cluster that already exists, and you cannot change the master key afterwards. It belongs with the other decisions you cannot undo.

It applies to shared-data clusters, which is what Anywhere runs, so there is nothing to check.

Choose a key service before you write the values file. Two are supported, and which one fits depends on what your network can reach:

	Where it runs	Reaches
HashiCorp Vault	Wherever you run it, including inside your own network	Works with no outbound connectivity
AWS KMS	Amazon's service	Needs a route to AWS

On a restricted or air-gapped network, Vault is the option that works: AWS KMS cannot be reached at all without outbound access.

What goes where

On Anywhere these are coordinator and compute-node configuration, so they go in the config: block of your values file, the same block that carries run_mode. Two rules decide which setting goes where:

Non-secret settings go in config:. That block becomes a ConfigMap.
Secrets do not. A ConfigMap is readable by anyone who can read the namespace, so vault_token, aws_kms_access_key and aws_kms_secret_key are passed as environment variables sourced from a Kubernetes Secret instead.

Create the Secret

# Vault
kubectl -n phoenixai create secret generic phoenixai-tde \
  --from-literal=vault-token='<vault-token>'

# or AWS KMS, if you authenticate with a key pair rather than an instance profile
kubectl -n phoenixai create secret generic phoenixai-tde \
  --from-literal=aws-access-key-id='<access-key>' \
  --from-literal=aws-secret-access-key='<secret-key>'

Coordinators

phoenixai:
  phoenixAICluster:
    phoenixAIFeSpec:
      config: |
        # ... the rest of your fe configuration ...

        # Vault
        vault_addr = <vault-address>
        default_master_key = vault:<secret-path>

        # or AWS KMS: name the key instead, and the region it lives in
        # default_master_key = kms:<key-id>
        # aws_kms_region = <region>
      feEnvVars:
        - name: VAULT_TOKEN
          valueFrom:
            secretKeyRef:
              name: phoenixai-tde
              key: vault-token

Compute nodes

The flag that turns encryption on lives here, not on the coordinators:

    phoenixAICnSpec:
      config: |
        # ... the rest of your cn configuration ...
        enable_transparent_data_encryption = true
      cnEnvVars:
        - name: VAULT_TOKEN
          valueFrom:
            secretKeyRef:
              name: phoenixai-tde
              key: vault-token

With AWS KMS, use AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in place of VAULT_TOKEN, sourced the same way. An instance profile needs neither.

componentValues replaces, it does not merge

If your values file sets phoenixai.phoenixAICluster.componentValues, a component's own block replaces it wholesale rather than merging into it. Put the TDE settings in the spec you actually want them on, and check the rendered output with helm template before installing.

The Vault secret itself

The value stored at <secret-path> is a formatted string, not a bare key:

aes_128:<Base64 encoding of the 128 bit key>

The settings

Coordinators (phoenixAIFeSpec.config)

Setting	For	What it is
`default_master_key`	both	`vault:<secret-path>`, or `kms:<key-id>`
`vault_addr`	Vault	The Vault server address
`vault_token`	Vault	A service token. Pass as `VAULT_TOKEN`, not here
`aws_kms_region`	AWS KMS	The region the key lives in
`aws_kms_access_key`, `aws_kms_secret_key`	AWS KMS	Pass as environment variables, not here. Unnecessary with an instance profile
`aws_kms_iam_role_arn`, `aws_kms_external_id`	AWS KMS	For assumed-role access

Compute nodes (phoenixAICnSpec.config)

Setting	What it is
`enable_transparent_data_encryption`	`true` turns encryption on

The AWS credential settings are also read here when you use a key pair.

Check it is working

These metrics are exported by the cluster once encryption is active:

Metric	Reports
`encryption_keys_created`	File encryption keys created
`encryption_keys_unwrapped`	Decryption operations
`encryption_keys_in_cache`	Keys currently held in the key cache
`encryption_bytes`	Bytes encrypted
`decryption_bytes`	Bytes decrypted

encryption_keys_created rising as you load data is the signal that files are being encrypted. See Anywhere Console monitoring for reading metrics.

Limitations

Shared-data clusters only. That is what Anywhere runs, so this is not a restriction here.
Cannot be enabled on an existing cluster, and the master key cannot be changed once set.
Expect a performance cost of under 10%.

Before you start​

What goes where​

Create the Secret​

Coordinators​

Compute nodes​

The Vault secret itself​

The settings​

Check it is working​

Limitations​