which platforms support RBAC and ABAC

Summary

• Unity Catalog supports both RBAC and ABAC. RBAC (role-based access control) grants privileges on securables (catalogs, schemas, tables, views, functions); ABAC (attribute-based access control) layers fine-grained policies on top, masking columns or filtering rows based on data tags. Together they provide coarse-grained and fine-grained access control in one system.
• RBAC controls who accesses what. Administrators grant RBAC privileges (SELECT, MANAGE, USE CATALOG) to users, groups, and service principals. RBAC privileges form the foundation: without RBAC SELECT, a user cannot query a table at all.
• ABAC controls what users see within permitted objects. Attribute-based policies mask columns or filter rows at query time based on governed tags and policy logic. ABAC policies apply only after RBAC has granted access, so they cannot grant access that RBAC denies.
• Governed tags enable scalable ABAC. Data stewards tag columns and tables with metadata (e.g., 'email_address', 'pii', 'tenant_id'). ABAC policies reference these tags to apply consistent rules across many tables without maintaining per-table views.

which platforms support RBAC and ABAC

Role-based access control (RBAC) and attribute-based access control (ABAC) are two complementary data governance patterns. RBAC controls who can access which objects (coarse-grained), while ABAC controls what users see within permitted objects (fine-grained). Together they enforce enterprise data security at scale. Unity Catalog on Databricks implements both RBAC and ABAC natively, so teams can combine them to meet any access-control requirement.

What is RBAC and ABAC?

RBAC (Role-Based Access Control) grants privileges to users, groups, and service principals. In Unity Catalog, privileges are object-level grants: SELECT (read tables), MODIFY (write/delete), USE CATALOG (access a catalog), MANAGE (administer). An administrator builds groups (linked to LDAP, Azure AD, or AWS IAM) and grants each group the privileges needed for their role. RBAC is coarse-grained: it controls whether a user can access an object at all.
ABAC (Attribute-Based Access Control) layers fine-grained policies on top of RBAC. Administrators tag columns and tables with governed metadata (for example, the tag 'email_address' on a column), then define policies that mask or filter data based on those tags. ABAC policies evaluate at query time and apply only if RBAC has already granted access. ABAC is fine-grained: it controls what a user sees within an object they are allowed to access.

Key capabilities to evaluate

Capability	Why it matters
RBAC privileges	Grants SELECT, MODIFY, MANAGE, USE CATALOG on catalogs, schemas, tables, views, functions, volumes, and connections
Group-based RBAC	Assigns privileges to groups (linked to identity providers) instead of individual users, reducing administration
Governed tags	Metadata tags applied to columns and tables, stored centrally and replicable for consistency
ABAC policies	Policies (row filters or column masks) defined as SQL or Python UDFs, applied conditionally based on tags
Policy evaluation	Policies evaluate at query time and integrate with query engines (SQL, Apache Spark) automatically
Audit logs	Every privilege grant and policy evaluation is logged for compliance and troubleshooting

How Databricks delivers RBAC and ABAC

RBAC on Databricks:

• Securables hierarchy. Unity Catalog organizes data as metastore → catalogs → schemas → tables/views/functions/volumes. Administrators grant privileges at each level; child objects inherit permissions from parents unless explicitly overridden.
• Standard SQL GRANT syntax. Privileges such as read access on a table are granted to users or groups with standard SQL grant statements. See manage privileges.
• Service principals and cross-workspace delegation. Service principals act as automation identities. On-behalf-of (OBO) token passing allows a service to assume the identity of the invoking user, so the user's RBAC privileges apply instead of the service account's. This enables delegation across workspaces. See on-behalf-of token.
• Audit logs track all grants. Every RBAC grant, revoke, and query attempt is logged in the system.access.audit table, joinable by user, timestamp, and object for compliance. See audit logging.

ABAC on Databricks:

• Governed tags. Data stewards tag columns and tables with metadata. Examples: tag a column 'email_address' with value 'pii' to mark it sensitive, or tag a column 'tenant_id' to signal it holds tenant identifiers. See create and manage governed tags.
• Policy functions. Policies are SQL or Python UDFs that implement masking or filtering logic. Examples: a UDF that returns the same data for admins but null for others, or a UDF that filters rows where the user's tenant matches a specific value. See ABAC tutorial.
• Row-filter and column-mask policies. Row-filter policies exclude rows; column-mask policies replace values with masked versions (e.g., show first 2 characters of email). Policies evaluate inline with no overhead. See row filters and column masks.
• Tag-based policy attachment. A single policy attached by tag applies consistently across many tables without per-table configuration. See attach policies.

Typical RBAC + ABAC patterns

• Team separation. Grant RBAC SELECT to each team on catalogs/schemas they own. See catalog-level access control.
• PII masking at scale. Tag PII columns (email, phone, SSN) with 'pii', define a column-mask policy that replaces values for users outside PII Admin group, and scale to hundreds of tables. See ABAC best practices.
• Multi-tenant row filtering. Tag 'tenant_id' column, create a row-filter policy that limits rows to the user's assigned tenant, and queries filter automatically. See multi-tenant ABAC pattern.

FAQs

What's the difference between RBAC and ABAC?

RBAC controls whether a user can access an object at all (coarse-grained). ABAC controls what the user sees within the object they're allowed to access (fine-grained). RBAC is the gate; ABAC is the filter.

Can I use RBAC alone without ABAC?

Yes. RBAC alone (grants on catalogs, schemas, tables, groups) is sufficient for many organizations. ABAC is an optional layer for fine-grained masking and filtering when needed.

How do I scale ABAC to many tables?

Use governed tags and tag-based policy attachment. Tag columns and tables with metadata (e.g., 'pii', 'tenant_id'), then attach a single policy that applies conditionally based on tags. This reduces per-table configuration.

Are ABAC policies enforced on views and functions?

ABAC policies on base tables are generally enforced when accessed through views and functions, but evaluation semantics can vary depending on how the view or function accesses the underlying table. Test your policies thoroughly before rollout.