How Apache Iceberg’s read restrictions and catalog labels unify lakehouse governance

# What changed Catalog: read restrictions and catalog labels. Together they address two separate governance problems that frequently arise in lakehouse environments: delegating enforcement to external compute engines, and making governance metadata portable across federated catalogs.

# Read restrictions: delegating policy enforcement Read restrictions formalize a contract between a catalog and a trusted engine. When a client requests a table via the Iceberg REST Catalog, the catalog evaluates applicable policies for that principal and returns concrete enforcement instructions — predefined column-projection actions and standardized row-filter expressions — which the trusted engine must apply while reading the data.

• It enables external engines that can be trusted to apply filters and masks to operate on governed data without routing every read through centralized filtering infrastructure.

• The engine receives the outcome of policy evaluation for a specific principal, not the original policy definition. That produces a common enforcement contract but can lose policy semantics when policies require constructs outside the spec's vocabulary.
• The initial spec defines a small, bounded vocabulary: nine predefined column-projection actions and simple row-filter expressions (comparisons, set membership). Enterprise policies relying on subqueries, lookup tables, or custom UDFs cannot be fully expressed as read restrictions.

Read restrictions are best when the source catalog can reduce policy outcomes to the spec's vocabulary and the compute engine can be securely configured so it cannot be subverted by end users. They are intended for direct engine-to-catalog access patterns where delegated enforcement yields operational benefits.

# Catalog labels: portable governance metadata

• Catalog labels make governance context portable between catalogs, supporting federation and multi-catalog access patterns without losing important policy metadata.

# Comparison: centralized versus delegated enforcement Centralized enforcement keeps evaluation and enforcement within the catalog environment. An example is routing reads through a secure filtering fleet that enforces row filters and column masks before any external engine sees the data.

Delegated enforcement pushes enforcement to a trusted external engine after the catalog returns concrete restrictions. Delegated enforcement reduces routing overhead and can allow engines to directly process filtered data, but it depends on a trustworthy runtime and on the policy being expressible within the read restrictions vocabulary.

# Implementation questions and next steps Operational teams must solve several practical questions:

• How to propagate the end user's identity and attributes securely to the engine so enforcement maps to the right principal?

• How to implement trust in the engine (mTLS, OAuth, or platform-specific controls) since the protocol leaves trust establishment outside its scope?

The Iceberg additions give a clear model for common access patterns and create opportunities for further tooling and deployment patterns. But teams should evaluate whether their policies can be expressed within the read restrictions vocabulary and design operational controls to lock down trusted engines.