ABAC: When Data Context Becomes the Access Rule
Attribute-Based Access Control uses identity and data attributes to decide access. This explainer shows how governed tags become row filters or column masks across data engines.
Loading…
Topic
5 posts about Attribute-Based Access Control. Every summary links to the original.
See the idea
Attribute-Based Access Control uses identity and data attributes to decide access. This explainer shows how governed tags become row filters or column masks across data engines.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
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.
Apache Iceberg’s REST Catalog additions—read restrictions and catalog labels—address different cross-platform governance problems: delegating enforcement to trusted engines and carrying governance context across federated catalogs. Read restrictions let a catalog evaluate policy for a principal and return bounded column-projection actions and row-filter expressions that a trusted engine must enforce, while leaving trust establishment outside the protocol. Catalog labels exchange opaque key-value metadata at table and column level, allowing a consuming catalog to map classifications locally, preserve native policy expressiveness, and maintain its own audit trail. Together with centralized enforcement through Cross-Engine ABAC, they provide distinct options for direct access and catalog federation, although read restrictions cannot express policies outside their standardized vocabulary.
The post argues that healthcare AI governance must extend beyond security controls to include knowledge, context, and ontology: security governs access, while semantics determine what data means and whether models can trust it. DEP frames classification tags, model cards, data contracts, and lineage as machine-readable governance artifacts, with Unity Catalog serving as the metadata runtime for agents. Build agents can generate ETL, testing, de-identification, and deployment, while analytic agents answer questions over individual data products; human stewards approve proposals and own accountability. A shared lifecycle certifies the data product and AI track through gates using scores for governance, quality, semantics, and ownership, with certification expiring after relevant changes or failures. The approach applies data-layer ABAC to SQL and vector retrieval, logs agent prompts with lineage, and connects readiness metrics to model economics by enabling smaller models when cataloged data supplies sufficient context.
Cross-engine ABAC is announced in Beta, extending Unity Catalog's fine-grained governance to external engines through Iceberg REST Catalog APIs. It supports tag-based row filters and column masks, including conditional logic and SQL UDFs, while allowing policies to be defined once and enforced across engines. For an external query, the engine sends a scan request, Unity Catalog evaluates entitlements and applicable policies, and returns a filtered scan plan before the engine processes authorized files. Enforcement remains at the catalog layer, so engines need not implement governance logic and can use the open scan APIs. Apache Spark is supported today through Iceberg-Spark and Delta-Spark connectors, with Starburst and DuckDB integrations coming soon; the Beta also points toward Apache Iceberg label exchange for future governance metadata sharing.
Unity Catalog now generally offers three complementary data-governance capabilities: Attribute-Based Access Control (ABAC) policies for row filtering and column masking, Governed Tags, and agentic Data Classification. They address per-object access rules, coordination gaps, and manual detection by letting governance teams define tag-based policies once, automatically classify sensitive data, and protect matching objects across catalogs and schemas. Governed tags provide an account-level vocabulary inherited across catalogs, schemas, tables, and columns, while ABAC applies row filters and column masks using tag-based conditions. Classification uses built-in compliance classifiers, custom classifiers, metadata, pattern recognition, and large language models, with human-in-the-loop validation and false-positive exclusions. General availability adds 10x larger policy limits, support for 10,000+ policies per metastore, lifecycle management through SQL, APIs, UI, and Terraform, expanded compliance coverage, and custom classifiers in beta.
The best engineering reads, once a week.