### What problem does this PR solve? Related PR: #70087 Problem Summary: Enabling Parquet modular encryption in Arrow does not implement native encrypted Iceberg reads in Doris. Scan planning currently has no shared admission check for an encrypted table. Ordinary scans can emit ranges without establishing encryption support, while metadata-only COUNT and system-table routes can bypass the native data reader altogether. For example, a v3 table whose SDK metadata contains `encryption.key-id` can reach scan planning and COUNT pushdown without any proof that the selected backends understand encrypted Iceberg tasks. This PR establishes the first-stage read contract before native execution is enabled. - Add `enable_encryption_read` to the Iceberg plugin's `iceberg.conf`, defaulting to `false`. This is deployment configuration requiring an FE restart, with no catalog/session override or fe.conf fallback. - Share admission checks across table metadata and snapshot binding, ordinary scans, COUNT eligibility/pushdown, streaming scans, system tables and explicitly empty snapshot pins. - Detect encryption from the table key property, retained v3 encryption keys, or a non-plaintext SDK manager. Removing the current write key must not admit old encrypted snapshots as plaintext. - Return stable classifications for disabled reads, unsupported catalogs/table formats/custom managers, and unavailable backend capabilities. Error text excludes key identifiers and encryption objects. - Even with the switch on, reject encrypted execution until backend capability negotiation and native readers exist. A declared encrypted table is rejected before KMS manager initialization or manifest I/O. Plaintext scans and exact metadata counts retain their behavior. The included developer contract defines the initial HMS / v3 / native Parquet `AES_GCM_V1` target and the requirements for explicit BE advertisement, placement, retries, key ownership and redaction. This PR deliberately adds no SPI/wire fields and grants no encrypted-write capability. Actual per-file format/algorithm validation and undeclared externally encrypted files remain part of the subsequent planner/reader work. ### Validation ```sh JAVA_TOOL_OPTIONS='-XX:ActiveProcessorCount=8' mvn -f fe/pom.xml -pl :fe-connector-iceberg -am package -Dmaven.build.cache.enabled=false mvn -f fe/pom.xml -pl :fe-connector-iceberg checkstyle:check ``` - The complete reactor package succeeded, including connector packaging and upstream module tests. Iceberg connector results: **1923 tests reported, 1909 passed, 14 existing skips, 0 failures, 0 errors**. - Added 8 contract tests and 1 configuration test. Real SDK metadata fixtures cover empty/populated tables, direct/cached acquisition, statement scopes, metadata binding, COUNT, streaming, system tables, retained keys, unsupported catalogs/v2/custom managers, error redaction and rejection before KMS initialization or manifest/data I/O. - Before the implementation, five initial contract tests failed because encrypted reads were admitted; the plaintext compatibility test passed. The final added contract/configuration tests all pass. - FE Checkstyle: **0 violations**. Verified that the plugin zip includes the admission class and the updated configuration template. - Local HTTP mock servers were run without proxy interception. The test JVM uses 8 processors so the existing cancellation fixtures do not trigger the SDK's automatic manifest-merge threshold. No existing test was changed or excluded for this. SQL regression coverage is included in `test_iceberg_encryption_read_guard`: ```sh bash run-regression-test.sh --run -d external_table_p0/iceberg \ -s test_iceberg_encryption_read_guard ``` - Built the full FE from this PR using `build.sh --fe`, and ran the suite with an isolated FE and an existing ASAN BE against the standard REST/MinIO fixture. - The SQL suite directly asserts the production default, `READ_DISABLED`, without a separate regression option for the expected FE switch state. It also sets a catalog-level `enable_encryption_read=true` to verify that a catalog cannot bypass the deployment-level setting. - Default plugin configuration: passed normal expected-output comparison; **96 admission-error assertions**, with both table-cache settings, both COUNT pushdown settings, populated/empty declarations, repeated queries, SELECT, COUNT, DESC and `$files` / `$snapshots` / `$position_deletes`. Plaintext rows and counts remain correct. - Connector unit tests explicitly construct both enabled and disabled plugin contexts; enabled REST contexts reject with `UNSUPPORTED_CATALOG`, and eligible HMS contexts reject with `BACKEND_CAPABILITY_UNAVAILABLE`. The ordinary SQL regression does not require an enabled FE deployment. - Mutation control: in a temporary runtime-only artifact, replaced the admission helper with a no-op. The suite failed at the first declared-table SELECT because the required `READ_DISABLED` error was absent. Restored and hash-verified the unmodified production artifact before the passing runs; no test hook is included in the source change. - The expected `.out` file was generated by the standard regression runner and then used for normal comparison. The suite was rerun against its existing remote tables, exercising repeatable fixture cleanup. FE Checkstyle was rechecked: 0 violations. These SQL tests use real v3 tables and plaintext data files with synthetic encryption declarations to isolate admission from decryption failures. They validate the FE/SQL guard, not native ciphertext decoding. Live KMS decryption, mixed-version cluster integration and full encrypted-query execution remain subsequent work. ### Release note Declared encrypted Iceberg tables now fail with clear read-admission errors. The plugin read switch defaults off, and enabling it cannot bypass unavailable backend support or enable encrypted writes. ### Check List (For Author) - Test - [x] Unit Test - [x] Regression test - [ ] Manual test - Behavior changed: - [x] Yes. Declared encrypted tables are rejected consistently before scan execution or metadata-count shortcuts. - Does this need documentation? - [x] Yes. Developer contract and configuration comments are included in this PR; public query documentation follows when encrypted execution is implemented. ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label
Guide for test cases
General Case
-
Write "def" before variable names; otherwise, they will be global variables and may be affected by other cases running in parallel.
Problematic code:
ret = ***Correct code:
def ret = *** -
Avoid setting global session variables or modifying cluster configurations in cases, as it may affect other cases.
Problematic code:
sql """set global enable_pipeline_x_engine=true;"""Correct code:
sql """set enable_pipeline_x_engine=true;""" -
If it is necessary to set global variables or modify cluster configurations, specify the case to run in a nonConcurrent manner.
-
For cases involving time-related operations, it is best to use fixed time values instead of dynamic values like the
now()function to prevent cases from failing after some time.Problematic code:
sql """select count(*) from table where created < now();"""Correct code:
sql """select count(*) from table where created < '2023-11-13';""" -
After streamloading in a case, add a sync to ensure stability when executing in a multi-FE environment.
Problematic code:
streamLoad { ... } sql """select count(*) from table """Correct code:
streamLoad { ... } sql """sync""" sql """select count(*) from table """ -
For UDF cases, make sure to copy the corresponding JAR file to all BE machines.
-
Do not create the same table in different cases under the same directory to avoid conflicts.
-
Cases injected should be marked as nonConcurrent and ensured injection to be removed after running the case.
-
Docker case run in a docker cluster. The docker cluster is new created and independent, not contains history data, not affect other cluster.
Docker case can add/drop/start/stop/restart fe and be, and specify fe and be num.
Example will see demo_p0/docker_action.groovy
Read the annotation carefully in the example file.
Also read the doris-compose readme.
-
Do not use raw
Thread.startorThread.startDaemonto run SQL in a case. Use the frameworkthreadorextraThreadhelper and callfuture.get()to wait for completion, so exceptions are reported to the case that created the thread.Problematic code:
def t = Thread.start { sql """insert into tbl values (1)""" } t.join()Correct code:
def future = thread("insert-thread") { sql """insert into tbl values (1)""" } future.get()
Compatibility case
Refers to the resources or rules created on the initial cluster during FE testing or upgrade testing, which can still be used normally after the cluster restart or upgrade, such as permissions, UDF, etc.
These cases need to be split into two files, load.groovy and xxxx.groovy, placed in a folder, and tagged with the restart_fe group label, example.