Loading post…
DatabricksDaniel Weeks, Ryan Blue, Andrei TserakhauExplainer
Read Restrictions and Catalog Labels: Unifying governance across engines and catalogs
Summary
The Apache Iceberg community has adopted two additions to the Iceberg REST Catalog — read restrictions and catalog labels — each addressing distinct governance challenges. Read restrictions standardize delegated enforcement: a catalog evaluates policy for a principal and returns column-projection actions and row-filter expressions from a bounded vocabulary for a trusted engine to enforce. Catalog labels enable portable governance by allowing catalogs to exchange opaque key-value metadata at table and column level, so a consuming catalog applies native policies without per-user calls to the source. Read restrictions suit engine-to-catalog access where the source catalog trusts the engine and policies fit the standard vocabulary, whereas catalog labels fit federation between heterogeneous catalogs needing scalable governance and independent audit trails. These building blocks, along with centralized enforcement via cross-engine ABAC, advance the vision of unified governance across the open lakehouse.
Context
The post is part of a series on open lakehouse governance, following previous discussions on cross-engine attribute-based access control (ABAC) via Unity Catalog. It explains two new features in the Iceberg REST Catalog spec.
Approach / What changed
Addition of read restrictions and catalog labels to the Apache Iceberg REST Catalog specification. Read restrictions provide a standard contract for delegated enforcement, allowing trusted engines to receive and enforce policy outcomes. Catalog labels enable portable governance context through opaque key-value metadata shared across federated catalogs.
Takeaways
Read restrictions return the policy outcome (row filters, column masks) using a bounded vocabulary of nine column-projection actions and standardized row-filter expressions, not the policy as defined.
Catalog labels are opaque key-value metadata at table and column level that allow consuming catalogs to apply native policies without per-user calls to the producing catalog, but have no shared semantics across catalogs.
Trust in delegated enforcement must be established outside the protocol via mechanisms like mTLS or OAuth, and the engine must prevent users from bypassing restrictions.
FAQ
How do read restrictions work compared to centralized enforcement?
In centralized enforcement, the catalog evaluates and enforces policy on a secure filtering fleet, never sending unauthorized data to the engine. In delegated enforcement (read restrictions), the catalog returns row filters and column masks for a trusted engine to enforce on its own.
What are catalog labels and what problem do they solve?
Catalog labels are key-value metadata shared between catalogs via Open APIs at table and column level. They make governance context portable across federated catalogs, so a consuming catalog can apply its own policies using the labels without needing to call the producing catalog for each access decision.
When should I use read restrictions versus catalog labels?
Read restrictions are best for engine-to-catalog access when the engine is trusted and policies fit the standard vocabulary. Catalog labels are better for federation between catalogs with different identity and policy models, enabling scalable governance without coupling catalogs.
Source and freshness
- Source
- databricks.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.