--- title: Standardizing fine-grained access control in Apache... description: Apache Iceberg's REST Catalog specification now includes a standardized read-restrictions field that lets catalogs express row filtering and column masking in... canonical: https://daily.dev/posts/standardizing-fine-grained-access-control-in-apache-iceberg-s-rest-catalog-nokrkorwv twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Standardizing fine-grained access control in Apache Iceberg's REST catalog | daily.dev og:description: Apache Iceberg's REST Catalog specification now includes a standardized read-restrictions field that lets catalogs express row filtering and column masking in... og:url: https://daily.dev/posts/standardizing-fine-grained-access-control-in-apache-iceberg-s-rest-catalog-nokrkorwv og:image: https://api.daily.dev/og/posts/NokrkORWV.png og:image:alt: Standardizing fine-grained access control in Apache Iceberg's REST catalog og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Standardizing fine-grained access control in Apache Iceberg's REST catalog **[Google Open Source Blog](https://daily.dev/sources/googleoss)** · 12 min read · 0 upvotes · 0 comments ## Summary Apache Iceberg's REST Catalog specification now includes a standardized read-restrictions field that lets catalogs express row filtering and column masking in an engine-neutral way. The change addresses a structural gap: Iceberg has no server in the read path, so once an engine gets a metadata pointer it has full file access, pushing fine-grained governance into proprietary vendor clients. The new spec defines nine closed masking actions (like mask-alphanum, sha-256-global, truncate-to-year), a required-row-filter predicate, and strict fail-closed semantics where unrecognized restrictions must cause query failure rather than silent data leakage. Restrictions reference field IDs rather than column names, are per-identity and per-response, and require trusted engines (e.g., shared Spark or Trino clusters) as the enforcement point since the protocol does not include attestation. The proposal passed with eight binding +1 votes and no objections; implementation work in engines and catalogs is now underway. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the read-restrictions field in Apache Iceberg's REST catalog specification? It is an optional object returned by loadTable that lets a catalog enforce row filtering and column masking in an engine-neutral way. It has two parts: required-row-filter, a standard Iceberg predicate hiding rows that evaluate false, and required-column-projections, a list of field-ID-identified columns with masking transformations applied after row filtering. _Teams rolling out Iceberg governance can follow implementation progress and engine support on daily.dev._ ### What masking actions does the Apache Iceberg read-restrictions spec define for column masking? Nine fixed actions: mask-alphanum, show-first-4, show-last-4, replace-with-null, mask-to-fixed-value, truncate-to-year, truncate-to-month, sha-256-global, and sha-256-query-local. Each has an exact per-type definition so Spark, Trino, and PyIceberg produce identical masked output, and every action preserves the input's original data type so query schemas never change. _Engineers comparing masking strategies across engines can track how these actions get implemented via daily.dev._ ### What happens if an engine does not support a read restriction returned by an Apache Iceberg catalog? The engine must fail the query rather than return raw, partial, or empty results. The specification mandates fail-closed behavior for any unrecognized masking action, unparseable filter expression, or duplicate field ID in column projections, ensuring the restriction vocabulary can grow in future versions without older engines becoming silent data leak vectors. _Developers hardening data access policies can keep up with evolving fail-closed standards on daily.dev._ ## Similar posts on daily.dev - [Unifying governance across engines and catalogs in the Open Lakehouse](https://daily.dev/posts/unifying-governance-across-engines-and-catalogs-in-the-open-lakehouse-qge5kcwda) · databricks · 0 upvotes · 0 comments - [The Open Interoperability Standard: Why Bidirectional Iceberg REST Matters](https://daily.dev/posts/the-open-interoperability-standard-why-bidirectional-iceberg-rest-matters-t1vcdckvz) · Snowflake · 0 upvotes · 0 comments - [Iceberg Needs an Open Catalog, Not a Walled Garden](https://daily.dev/posts/iceberg-needs-an-open-catalog-not-a-walled-garden-znv0xeptl) · SingleStore · 0 upvotes · 0 comments - [The Apache Polaris REST API Explained](https://daily.dev/posts/the-apache-polaris-rest-api-explained-jzkzrhix6) · Dremio Blog · 0 upvotes · 0 comments - [Apache Iceberg Architecture Deep Dive](https://daily.dev/posts/apache-iceberg-architecture-deep-dive-1znwuwiy4) · BigData Boutique blog · 5 upvotes · 0 comments --- Tags: [#big-data](https://daily.dev/tags/big-data), [#apache-iceberg](https://daily.dev/tags/apache-iceberg) [View this post on daily.dev](https://daily.dev/posts/standardizing-fine-grained-access-control-in-apache-iceberg-s-rest-catalog-nokrkorwv) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Standardizing fine-grained access control in Apache Iceberg's REST catalog","url":"https://daily.dev/posts/standardizing-fine-grained-access-control-in-apache-iceberg-s-rest-catalog-nokrkorwv","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/standardizing-fine-grained-access-control-in-apache-iceberg-s-rest-catalog-nokrkorwv"},"datePublished":"2026-10-01T18:48:41.920Z","dateModified":"2026-10-01T21:08:20.001Z","description":"Apache Iceberg's REST Catalog specification now includes a standardized read-restrictions field that lets catalogs express row filtering and column masking in...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/19cdd92f89d302559790880036b450a9?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/19cdd92f89d302559790880036b450a9?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Google Open Source Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Google Open Source Blog","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/8a87f457bf1a481b80c313f66a71200b","url":"https://daily.dev/sources/googleoss"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/standardizing-fine-grained-access-control-in-apache-iceberg-s-rest-catalog-nokrkorwv","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"big-data,apache-iceberg","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Google Open Source Blog","item":"https://daily.dev/sources/googleoss"},{"@type":"ListItem","position":3,"name":"Standardizing fine-grained access control in Apache Iceberg's REST catalog"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/standardizing-fine-grained-access-control-in-apache-iceberg-s-rest-catalog-nokrkorwv#faq","mainEntity":[{"@type":"Question","name":"What is the read-restrictions field in Apache Iceberg's REST catalog specification?","acceptedAnswer":{"@type":"Answer","text":"It is an optional object returned by loadTable that lets a catalog enforce row filtering and column masking in an engine-neutral way. It has two parts: required-row-filter, a standard Iceberg predicate hiding rows that evaluate false, and required-column-projections, a list of field-ID-identified columns with masking transformations applied after row filtering. Teams rolling out Iceberg governance can follow implementation progress and engine support on daily.dev."}},{"@type":"Question","name":"What masking actions does the Apache Iceberg read-restrictions spec define for column masking?","acceptedAnswer":{"@type":"Answer","text":"Nine fixed actions: mask-alphanum, show-first-4, show-last-4, replace-with-null, mask-to-fixed-value, truncate-to-year, truncate-to-month, sha-256-global, and sha-256-query-local. Each has an exact per-type definition so Spark, Trino, and PyIceberg produce identical masked output, and every action preserves the input's original data type so query schemas never change. Engineers comparing masking strategies across engines can track how these actions get implemented via daily.dev."}},{"@type":"Question","name":"What happens if an engine does not support a read restriction returned by an Apache Iceberg catalog?","acceptedAnswer":{"@type":"Answer","text":"The engine must fail the query rather than return raw, partial, or empty results. The specification mandates fail-closed behavior for any unrecognized masking action, unparseable filter expression, or duplicate field ID in column projections, ensuring the restriction vocabulary can grow in future versions without older engines becoming silent data leak vectors. Developers hardening data access policies can keep up with evolving fail-closed standards on daily.dev."}}]} ```