@Rocky Is starrocks capable of encrypting data at rest in shared_data mode ? Also, can it have different keys? 1 for each database for instance. Lastly, how do you set this up, if possible ?

Yes, StarRocks is capable of encrypting data at rest in shared-data (cloud-native) mode. This is achieved through Transparent Data Encryption (TDE), which was introduced in version v3.3.1 and further refined in v3.4.0 and later. 1. Capability in shared-data mode StarRocks supports TDE for newly written storage objects, including lake SSTs (used in shared-data clusters), segment files, and persistent index files. When enabled, data is encrypted before being written to the remote object storage (S3, GCS, etc.) or local cache. 2. Different keys per database According to current public documentation and feature sets: * Granularity: TDE is primarily managed at the cluster level through a centralized Key Management system. * Per-Database Keys: There is currently no explicit support in the public DDL (like

CREATE DATABASE

) to specify a different encryption key for each database. The encryption process uses a Key Encryption Key (KEK) and Data Encryption Keys (DEKs) managed by a

KeyManager

in the Frontend (FE) and cached on the Backend/CN nodes. * Inference: While the internal architecture (using KEK/DEK) is designed for flexibility, the user-facing capability to assign unique keys to specific databases is not a standard documented feature as of version 3.4/3.5. 3. How to set this up The setup involves configuring both the Backend (BE/CN) and the Frontend (FE). Backend/Compute Node Configuration In your

be.conf

or

cn.conf

, you must enable the feature:

properties
enable_transparent_data_encryption = true

* Note: This flag is not runtime-mutable; you must set it before starting the nodes. The FE and BE/CN encryption flags must match, or the cluster will fail to start. Frontend/Key Management Configuration For TDE to work, StarRocks requires a Key Management Service (KMS) integration or a Master Key to manage the KEK. * KEK Management: The Frontend (FE) implements a

KeyManager

to handle encryption metadata. * KeyCache: Backend nodes request encryption info from a

KeyCache

provided by the FE. Caution: As of the latest stable releases, the detailed configuration for external KMS providers (like AWS KMS or HashiCorp Vault) is often handled via specific enterprise-grade or internal configuration keys that are not yet fully detailed in the public "open source" documentation. If you are looking for per-database encryption specifically for multi-tenant isolation, it is recommended to: 1. Verify the specific KMS configuration requirements for your version in the StarRocks GitHub repository or release notes. 2. Reach out to the StarRocks community on Slack for the latest implementation status of multi-key support for KEKs. References • administration/management/FE_configuration.md • administration/management/BE_configuration.md