Databricks Details Two New Apache Iceberg Specs for Cross-Catalog Governance
Databricks describes two new Apache Iceberg specs, read restrictions and catalog labels, aimed at standardizing policy enforcement across engines and catalogs.
ひとことで言うと
What did Databricks announce about governance in the Open Lakehouse?
Databricks says the Apache Iceberg community has adopted two new specifications, read restrictions and catalog labels, to the Iceberg REST Catalog. Read restrictions let catalogs delegate policy enforcement to trusted engines, while catalog labels let catalogs exchange governance metadata, such as PII tags, across federated systems like Unity Catalog and Snowflake.
要点
- Databricks reports that the Apache Iceberg community has advanced two additions to the Iceberg REST Catalog: read restrictions and catalog labels.
- Read restrictions let a catalog evaluate access policy for a user and return row-filter and column-projection instructions that a trusted engine, such as a securely configured Trino deployment, must enforce; Databricks says untrusted engines like Spark or DuckDB require centralized enforcement instead.
- Databricks states the read restrictions spec defines nine predefined column-projection actions and standardized row-filter expressions, but does not define how a catalog establishes trust with an engine.
- Catalog labels, according to Databricks, allow catalogs such as Unity Catalog, Snowflake, AWS Lake Formation and Google Cloud Knowledge Catalog to exchange key-value metadata at the table and column level, which the receiving catalog maps into its own tagging or policy model.
- Databricks notes that labels are opaque key-value pairs with no shared semantics, so enterprises still need their own conventions to interpret them consistently across catalogs.
Databricks published details on two new specifications adopted by the Apache Iceberg community for the Iceberg REST Catalog: read restrictions and catalog labels. The company says both are meant to standardize how governance policies are enforced when data is accessed across different compute engines and federated catalogs.
Read restrictions
Databricks describes read restrictions as addressing a common scenario in which an organization governs data in one catalog but wants to query it using different engines or tools. Under this model, the catalog evaluates a requesting user's identity and context, decides what row filters or column masks apply, and returns those restrictions to an engine it trusts to enforce them.
Databricks distinguishes this from centralized enforcement, where all steps happen inside the catalog's own environment. The company gives its own implementation as an example, saying Databricks applies fine-grained access control on dedicated compute by routing queries through what it calls a secure filtering fleet, and that its Unity Catalog Cross-engine ABAC feature extends this to other engines through the Iceberg REST catalog's scan and plan APIs.
For delegated enforcement, Databricks says the engine does not receive the policy as an administrator wrote it, but rather the resulting filtering or masking instructions for that specific user. The company states the initial spec defines nine predefined column-projection actions and standardized row-filter expressions, such as comparisons or set membership, and notes that policies relying on subqueries, lookup tables, or custom UDFs cannot currently be expressed this way.
Databricks also notes the specification does not define how a catalog establishes that an engine is trustworthy, saying a claim from the client alone is not sufficient and that system administrators must apply their own security mechanisms. The company points to Iceberg community discussions that have considered options including mTLS and OAuth, while stating that trust remains outside the protocol itself. Databricks says a securely configured Trino deployment is an example of a trusted engine, while Spark and DuckDB are considered untrusted when users control the runtime and can execute arbitrary code.
Catalog labels
The second specification, catalog labels, addresses governance across federated catalogs, according to Databricks. The company notes that many enterprises now connect multiple catalogs, including Unity Catalog, Snowflake, AWS Lake Formation, and Google Cloud Knowledge Catalog, each with its own identity models and policy languages.
Databricks explains that labels let a producing catalog attach lightweight key-value metadata to tables and columns, which a consuming catalog then maps into its own classifications or tagging system before applying its native policies. As an example, the company describes a producing catalog labeling a column "ssn" with "pii=ssn," which a consuming catalog could use to trigger a masking policy.
Databricks states that because enforcement stays local to the consuming catalog, each system preserves its own policy expressiveness and maintains independent audit trails, without needing to call another catalog for every access decision. The company cautions that labels are opaque key-value pairs with no shared semantics or stable identifiers defined by the standard, meaning a consuming catalog sees only the resolved label, not the purpose it was intended for. Databricks says enterprises will still need their own conventions or explicit mappings to interpret labels consistently.
Applying the two models
Databricks summarizes the choice between approaches as depending on the destination: centralized enforcement for untrusted engines, read restrictions for trusted engines, and catalog labels for catalog-to-catalog federation.
Source: Databricks Blog, "Unifying governance across engines and catalogs in the Open Lakehouse," published September 10, 2026.
よくある質問
- What are read restrictions?
- Databricks describes read restrictions as a new Iceberg REST Catalog contract in which a catalog evaluates access policy for a requesting user and returns row-filter and column-projection instructions that a trusted engine must enforce when reading a table.
- What are catalog labels?
- According to Databricks, catalog labels let a producing catalog attach key-value metadata, such as marking a column as containing PII, to tables and columns, which a consuming catalog can map into its own governance model during federation.
- Which engines count as trusted under read restrictions?
- Databricks gives a securely configured Trino deployment as an example of a trusted engine, since it provides native enforcement of row filters and column masks, while it lists Spark and DuckDB as untrusted when users control the runtime.
- Does the read restrictions spec define how trust is established?
- No. Databricks says the specification defines what a trusted engine must enforce but not how a catalog verifies that trust, noting the Iceberg community has discussed mechanisms such as mTLS and OAuth.