@Rocky does Starrocks (any version) support Iceberg encryption or data isolation? https://iceberg.apache.org/docs/nightly/encryption/

StarRocks does not currently support native Iceberg file-level encryption (Parquet Modular Encryption), but it provides robust mechanisms for data isolation and storage-level encryption. 1. Iceberg Encryption Support * Iceberg Native Encryption (Unsupported): StarRocks does not yet support the native Iceberg encryption mechanism (described in your link) that uses an Iceberg Encryption Manager and Parquet Modular Encryption to encrypt individual data and manifest files. * An active GitHub issue (#56587) confirms that as of late 2025, StarRocks' C++ execution engine does not yet have the logic to handle the

encryption.kms-type

or

encryption.key-id

properties for file decryption. * Storage-Level Encryption (Supported): StarRocks supports Server-Side Encryption (SSE) provided by storage backends (like AWS S3 SSE-KMS or SSE-S3). Because this encryption is handled transparently by the cloud provider's SDK, StarRocks can query these tables as long as the cluster has the appropriate IAM permissions to access the KMS keys. 2. Data Isolation StarRocks offers several ways to achieve data and workload isolation for Iceberg tables: * Compute Isolation (Multi-Warehouse): Since version 3.0, StarRocks' shared-data architecture allows you to deploy multiple, independent Compute Node (CN) groups. You can isolate workloads (e.g., "Reporting" vs. "Data Science") by assigning them to different compute clusters that query the same underlying Iceberg data. * Access Control Isolation (RBAC): StarRocks supports a native Role-Based Access Control (RBAC) model for external catalogs. You can grant fine-grained permissions (

SELECT

,

USAGE

) on specific Iceberg databases and tables to different users or roles. * Catalog-Centric Security (v4.0+): By using an Iceberg REST Catalog (like Apache Polaris), StarRocks can implement "Identity Passthrough." * JWT Passthrough: StarRocks forwards the user's JWT token to the REST catalog. * Vended Credentials: The catalog verifies permissions and "vends" temporary, short-lived storage credentials back to StarRocks, ensuring the engine never holds long-lived master keys and that access is isolated at the user level. Summary Table Feature | Supported | Notes Iceberg Native Encryption | ❌ No | Native Parquet Modular Encryption is not supported. Storage SSE-KMS | ✅ Yes | Supported via standard AWS/GCS/Azure SDK integration. Compute Isolation | ✅ Yes | Via stateless CN groups (Compute-Storage separation). Data Isolation | ✅ Yes | Via native RBAC and Iceberg REST Catalog (Vended Credentials). Recommendation: For data isolation, use the Iceberg REST Catalog with Vended Credentials (available from v4.0). This provides the most secure and isolated architecture currently available for StarRocks and Iceberg. References • data_source/catalog/iceberg/iceberg_catalog.md

@Rocky are there any open issues or pull requests on the topic?

StarRocks does not currently support native Iceberg file-level encryption (Parquet Modular Encryption), but as of version 4.0, it provides advanced support for data isolation through catalog-level security. 1. Iceberg Encryption Support * Native Iceberg Encryption (Unsupported): StarRocks does not yet support the native Iceberg encryption mechanism (Parquet Modular Encryption) that uses an Iceberg Encryption Manager and KMS to encrypt individual data and manifest files. Decrypting these files requires specific logic in the engine's reader (C++ for StarRocks), which is not yet implemented. * Storage-Level Encryption (Supported): You can use Server-Side Encryption (SSE) provided by your storage provider (e.g., AWS S3 SSE-KMS or SSE-S3). Because this is handled transparently by the storage layer, StarRocks can query these tables if the cluster has the necessary IAM permissions to access the keys. 2. Data Isolation (v4.0+) StarRocks 4.0 introduced significant features for data and workload isolation specifically for Iceberg: * Vended Credentials: When using an Iceberg REST Catalog (like Apache Polaris or Lakekeeper), the catalog can "vend" temporary, short-lived storage credentials to StarRocks. This ensures StarRocks only has access to the specific files needed for a query, isolating storage access at the session level. * JWT Identity Passthrough: StarRocks can forward a user's JWT token to the REST catalog. This allows the catalog to enforce fine-grained permissions based on the actual user's identity, providing strict data isolation between different users querying the same lakehouse. * Compute Isolation: Using StarRocks' shared-data architecture, you can create multiple independent compute groups (CN groups) to isolate workloads (e.g., isolating ETL from BI) while querying the same Iceberg data. 3. Open Issues and Pull Requests There is no single "PME support" pull request currently open, as this is a complex feature involving the C++ execution engine. Most community activity is focused on improving the Iceberg REST Catalog integration: * Vended Credentials (PRs in v4.0): Recent work has finalized support for vended credentials and JWT authentication. * Iceberg REST Improvements: Issues like #56600 discuss refining how StarRocks interacts with REST catalogs to better support managed environments and isolation. Summary Table Feature | Supported | Version Iceberg Native Encryption (PME) | ❌ No | - Storage-Level SSE-KMS | ✅ Yes | All Vended Credentials | ✅ Yes | v4.0+ JWT Identity Passthrough | ✅ Yes | v4.0+ Compute/Workload Isolation | ✅ Yes | v3.0+ For sensitive data, the current recommended architecture is to use StarRocks 4.0 with an Iceberg REST Catalog and SSE-KMS at the storage layer.