# Standardizing fine-grained access control in Apache Iceberg's REST catalog

DevFeed: [Standardizing fine-grained access control in Apache Iceberg's REST catalog](<https://devfeed.tech/articles/standardizing-fine-grained-access-control-in-apache-iceberg-s-rest-catalog-63652.md>)

Original publisher: [Read original article](<http://opensource.googleblog.com/2026/10/standardizing-fine-grained-access-control-in-apache-icebergs-rest-catalog.html>)

Author: Google Open Source (noreply@blogger.com)

Published: 2026-10-01T18:30:00Z

Content type: article

Language: en

Sources: [Google Open Source Blog](<https://devfeed.tech/sources/google-open-source-blog.md>)

Topics: [Apache Iceberg](<https://devfeed.tech/topics/apache-iceberg.md>), [Access Control](<https://devfeed.tech/topics/access-control.md>), [parquet](<https://devfeed.tech/topics/parquet.md>), [elasticsearch](<https://devfeed.tech/topics/elasticsearch.md>), [Apache Spark](<https://devfeed.tech/topics/spark.md>), [Apache Flink](<https://devfeed.tech/topics/apache-flink.md>), [DuckDB](<https://devfeed.tech/topics/duckdb.md>)

Tags: [access-control](<https://devfeed.tech/tags/access-control.md>), [apache-iceberg](<https://devfeed.tech/tags/apache-iceberg.md>), [bigquery](<https://devfeed.tech/tags/bigquery.md>), [data-governance](<https://devfeed.tech/tags/data-governance.md>), [database](<https://devfeed.tech/tags/database.md>), [duckdb](<https://devfeed.tech/tags/duckdb.md>), [flink](<https://devfeed.tech/tags/flink.md>), [lakehouse](<https://devfeed.tech/tags/lakehouse.md>), [object-storage](<https://devfeed.tech/tags/object-storage.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [parquet](<https://devfeed.tech/tags/parquet.md>), [spark](<https://devfeed.tech/tags/spark.md>)

## AI overview

Apache Iceberg's REST Catalog specification now defines engine-neutral read restrictions for row filtering and column masking. Catalogs return evaluated restrictions for trusted readers, which must fail closed if they cannot apply them. The article explains the masking actions, trust assumptions, and remaining gaps, including the lack of portable policy definitions and engine attestation.

## Source excerpt

by Talat Uyarer & Sung Yun, Google Cloud The Apache Iceberg community recently merged a change to the REST Catalog specification that gives lakehouses something they have long been missing: a standard, engine-neutral way to express column masking and row filtering. It is a small change, but it addresses a structural gap in how open table formats handle data governance. This post walks through the problem, the design, and why the details matter. The problem: there is no server in the read path In a traditional database, access control is straightforward because there is exactly one door. Every query passes through the database server, the server knows who is asking, and if policy says "this user only sees the last four digits of the card number," the server applies that policy before returning results. One process, one enforcement point. Apache Iceberg deliberately removed that door. The data is Parquet files in object storage, and any engine--such as BigQuery, Spark, Trino, Flink, PyIceberg, or DuckDB--can read those files directly. This design is what makes Iceberg fast and interoperable. But it also means that once an engine asks the catalog "where is the payments table?" and receives the metadata pointer, it has full access to the files. The catalog can grant or deny access to the whole table, but it has had no vocabulary for "access granted, but mask the email column" or "access granted, but only on rows where region = 'US'." Until now, Iceberg had no built-in answer to this. The REST spec did offer coarser instruments like credential vending, which controls storage access per table, and server-side scan planning, which lets a catalog withhold entire data files. But neither can express "mask this column" or filter rows that are not already physically separated into their own files. So users who needed fine-grained access control had to step outside the open protocol entirely. They could adopt a vendor-provided client that understands its proprietary policy format,