Read Restrictions and Catalog Labels: Unified Data Governance Across Engines

Background: The Fragmentation Problem in Data Governance

As enterprise data stacks grow increasingly complex, data is often scattered across multiple query engines, storage formats, and metadata catalogs. The combination of open table formats, open APIs, and unified governance is widely seen as the key to solving this challenge. The core topics here revolve around Read Restrictions and Catalog Labels — two mechanisms for unifying governance policies across different engines and catalogs.

Read Restrictions: Fine-Grained Access Control

Read restrictions are one of the foundational capabilities of modern data governance. They allow administrators to control data access at the row, column, or even cell level, ensuring that only authorized users can view sensitive fields. In multi-engine environments, the key challenge with these restrictions is consistency — when the same data is accessed by different engines such as Spark, Trino, or Presto, governance rules must remain uniform and cannot leak permissions due to engine-specific differences.

The ideal architecture abstracts access policies to a governance layer, where the catalog distributes them centrally rather than requiring repeated configuration in each engine. This reduces operational overhead and prevents compliance risks from policy drift.

At the implementation level, Row-Level Security (RLS) is typically achieved by dynamically injecting filter conditions at query execution time — for example, Apache Ranger or Apache Atlas intercepts query requests and appends WHERE clauses. Column-level security is enforced through column masking via views or by directly rejecting column projections. Cell-level control is the most complex, requiring cross-validation of both row and column conditions. Notably, Spark's RLS implementation relies on extensions to the DataSourceV2 interface, while Trino injects policies through its built-in SystemAccessControl SPI (Service Provider Interface) — two architecturally distinct approaches that are precisely the root cause of policy drift risk. A unified governance layer needs to abstract away these engine differences and expose an engine-agnostic policy description language (such as OPA policies or YAML configuration), which an adapter layer then translates into execution instructions each engine understands.

Catalog Labels: The Vehicle and Propagation Mechanism for Policies

Catalog Labels provide a declarative approach to governance. By tagging tables, columns, or data assets with semantic labels (such as PII, Confidential, or Internal), the governance system can apply policies in bulk based on those labels — without manually configuring each individual object.

This tag-based access control (TBAC) model offers several advantages:

• Scalability: Newly added data assets simply need to be tagged to automatically inherit the corresponding policies;
• Cross-catalog consistency: Tag semantics remain unified across different catalogs, and policies propagate as data flows;
• Auditability: Labels themselves serve as clear documentation of governance intent.

Conceptually, Tag-Based Access Control (TBAC) is closely related to Attribute-Based Access Control (ABAC) — labels are essentially attributes of data assets, and the policy engine makes dynamic decisions based on combinations of subject attributes, asset attributes, and environmental attributes. Compared to traditional Role-Based Access Control (RBAC), TBAC has a clear advantage as data volumes scale rapidly: there's no need to manually assign permissions for every new table, as long as the tagging process is well-governed. That said, the industry has yet to establish a unified standard for tag semantics. AWS Glue, Apache Atlas, Unity Catalog, and others each maintain their own tagging systems, making cross-platform tag mapping an additional governance burden in itself. Apache Atlas offers a relatively mature label propagation mechanism that can automatically inherit parent asset tags to child assets, but this capability is not common across other catalogs.

The Value and Challenges of Unified Governance

Combining read restrictions with catalog labels is fundamentally about building an engine-agnostic, storage-format-agnostic governance control plane. This aligns closely with the philosophy of open table formats (such as Apache Iceberg) and open APIs — just as data should not be locked into a single vendor's technology stack, governance policies should likewise be portable.

However, achieving unified governance across engines still faces real-world challenges: varying degrees of support for policy pushdown across different engines, a lack of industry consensus on tag semantic standardization, and the tradeoffs between performance and security. These are all critical areas for enterprises to evaluate carefully when implementing such solutions.

As one of the most prominent open table formats today, Apache Iceberg is designed to naturally support governance integration: its separation of the metadata layer from data files allows catalogs to attach governance attributes without modifying the underlying data, and its snapshot isolation mechanism provides built-in historical versioning for auditing. When multiple engines access the same Iceberg table, the depth of predicate pushdown directly impacts security — if an engine bypasses the governance layer's row-level filtering when reading Parquet files, permission leakage can occur. The "performance vs. security tradeoff" is therefore fundamentally a question of whether to allow engines to read underlying files directly while bypassing the governance layer, or to enforce all access through a governance proxy. The latter is more secure but introduces latency. How to guarantee complete policy enforcement without sacrificing query performance is an engineering challenge that major vendors are actively working to solve.

Summary

Read restrictions and catalog labels are two critical pieces of the unified data governance puzzle. The former addresses the fine-grained control problem of "who can see what," while the latter provides a mechanism for scaling policy propagation. Together, combined with open table formats and open APIs, they offer a path toward a consistent, auditable governance framework for enterprises operating in complex multi-engine, multi-catalog environments.

(Note: This article is based on limited source material. For specific product implementation details, please refer to the official documentation.)