---
title: "Read Restrictions and Catalog Labels: Unifying governance across engines and catalogs"
description: "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."
---

# Read Restrictions and Catalog Labels: Unifying governance across engines and catalogs

[Databricks](https://yomu.fyi/company/databricks) · Daniel Weeks, Ryan Blue, Andrei Tserakhau · Sep 30, 2026

**Type:** Explainer

## 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.

**Tags:** [Apache Iceberg](https://yomu.fyi/topic/apache-iceberg), [Attribute-Based Access Control](https://yomu.fyi/topic/attribute-based-access-control), [Data Governance](https://yomu.fyi/topic/data-governance), [REST APIs](https://yomu.fyi/topic/rest-api)

- Source: [Databricks](https://www.databricks.com/blog/unifying-governance-across-engines-and-catalogs)
- Source URL: https://www.databricks.com/blog/unifying-governance-across-engines-and-catalogs
- Ingested by Yomu: 2026-09-30T18:00:10.966Z

[Read original post](https://www.databricks.com/blog/unifying-governance-across-engines-and-catalogs)