How do you apply fine-grained access control and row-level security to Apache Iceberg tables?

Summary

• Yes. Unity Catalog applies the same fine-grained controls to Apache Iceberg tables that it applies to Delta tables: row filters for row-level security, column masks for column-level protection, and attribute-based access control (ABAC) driven by governed tags.
• Managed Iceberg tables are governed as first-class objects, so grants, row filters, column masks, lineage, and audit all apply and are enforced in the Databricks query engine.
• Iceberg is built to be read by many engines, so the hard part is enforcing row and column security when an external engine reads the table. Unity Catalog does not vend raw storage credentials for any table that carries fine-grained policies.
• With cross-engine ABAC (Beta), Unity Catalog evaluates policies during server-side scan planning over the Iceberg REST Catalog and returns a filtered scan, so an external engine only receives authorized rows and columns.
• Define policy once with governed tags and it applies across many Iceberg tables, covering new tables the moment they are tagged.

How do you apply fine-grained access control and row-level security to Apache Iceberg tables?

Yes, you can enforce row-level security and column-level controls on Apache Iceberg tables, and on Databricks you do it the same way you do for Delta tables: through Unity Catalog. A row filter hides rows a user cannot see, a column mask redacts sensitive values, and attribute-based access control (ABAC) applies both through governed tags rather than table by table. The Iceberg-specific challenge is enforcement across engines, because an Iceberg table is meant to be read by more than one query engine. Unity Catalog handles that by refusing to hand out raw storage credentials for any table that carries fine-grained policies, so no external engine can read around the rules.

What changes when the data is in Iceberg?

The access-control model does not change; the enforcement path does. When a query runs on a Databricks engine, Unity Catalog applies row filters, column masks, and grants inside the engine, exactly as it does for Delta. When an external engine reads an Iceberg table, no Databricks engine is in the loop, so the question is how to stop that engine from reading the files directly. Unity Catalog answers it by making credential vending conditional on the table's policies.

Key requirements for fine-grained access control on Iceberg tables

Requirement	Why it matters
Governed as a catalog object	The Iceberg table has to be a securable object in the catalog so grants, filters, and masks attach to it.
Row and column controls	Row filters and column masks restrict data inside the table, so one governed table replaces many filtered copies.
Tag-driven policy	ABAC policies on governed tags apply one rule across many tables and cover new tables as soon as they are tagged.
Engine-side enforcement	Controls must fire below the query so a notebook, BI tool, or agent cannot bypass them.
Cross-engine enforcement	When an external engine reads the table, the platform has to return only authorized data, not vend raw file access.
Lineage and audit	Every read should be captured, with column-level lineage, as compliance evidence.

How Databricks approaches it

Unity Catalog governs Apache Iceberg tables as first-class objects. Managed Iceberg tables are generally available, and they get the full governance model: grants, row filters, column masks, ABAC, lineage, and audit.

• Row-level security and column masking. A row filter is a SQL function evaluated per row at query time; rows where it returns FALSE are excluded. A column mask is a SQL function that returns the original or a masked value. Both are defined once and attached to the Iceberg table.
• ABAC with governed tags. Attribute-based policies evaluate governed tags, so a single policy can filter or mask every Iceberg table tagged a given way, and it covers new tables automatically. ABAC row filter and column mask policies are generally available.
• Enforcement on Databricks engines. For queries on Databricks, filters, masks, and grants are enforced in the SQL engine, so the same policy applies from notebooks, Databricks SQL, jobs, Genie, and agents.
• Cross-engine enforcement (Beta). For external engines, cross-engine ABAC enforces the same policies through the Iceberg REST Catalog. When a table carries fine-grained policies, Unity Catalog does not vend storage credentials. It evaluates the policies during server-side scan planning and returns a filtered scan, so the external engine receives only the rows and columns the user is entitled to. Cross-engine enforcement is in Beta and has setup requirements, including enabling external data access on the metastore and using managed tables with server-side planning.
• Managed and foreign Iceberg. Unity Catalog governs both Iceberg tables it manages directly and Iceberg tables registered from external catalogs through Lakehouse Federation, applying its access controls in each case.

For the design behind this, read Unity Catalog and the next era of Apache Iceberg and open storage, open access, unified governance.

FAQs

Can Unity Catalog enforce row-level security on Iceberg tables?

Yes. Row filters restrict which rows a user sees, defined once as a SQL function and attached to the Iceberg table. On Databricks engines the filter is enforced in the query engine; for external engines, cross-engine ABAC (Beta) returns a filtered scan so only authorized rows are read.

How are policies enforced when an external engine reads the table?

Unity Catalog does not vend raw storage credentials for a table that carries fine-grained policies. It uses the Iceberg REST Catalog scan APIs to evaluate the policies during server-side scan planning and return a filtered scan, so the external engine only receives authorized data. This is the cross-engine ABAC capability, currently in Beta.

Do I define access rules differently for Iceberg than for Delta?

No. You use the same row filters, column masks, and ABAC policies. The control model is identical; only the enforcement path differs when a non-Databricks engine reads the table.

Are these controls generally available?

Managed Iceberg tables and ABAC row filter and column mask policies are generally available. Cross-engine enforcement for external engines is in Beta, so confirm the current requirements before relying on it in production.