RBAC vs ABAC: Access Control for a Governed Lakehouse (with RLS and CLS)

RBAC assigns permissions based on a user’s role. The question it answers is simple: what role do you have, and therefore what can you access? You define roles or groups — Finance Analysts, Sales Analysts, Data Engineers, Data Scientists — grant each the appropriate privileges, and assign users to groups rather than granting them individually.

So a Finance Analyst group gets SELECT on finance data; Data Engineers get SELECT, MODIFY and CREATE; a Data Scientist gets SELECT on curated data. When someone joins or moves, you change their group membership, not a pile of individual grants. That is what makes RBAC manageable at scale — you administer roles, not people.

RBAC is the right model for standard organisational access patterns, and it is where most governance should start. It is simple, auditable and easy to reason about. Its limit is that it cannot express conditional rules that depend on the data itself.

ABAC decides access from attributes rather than roles alone. It can consider attributes of the user (department, country, clearance), of the resource (classification, owning department, country), and of the context (network, time). A policy then combines them: allow access when the user’s department matches the data’s department and the user has the required clearance.

A concrete example: a Finance Manager in the UAE with confidential clearance can see finance data classified confidential for the UAE — but the same role in another country would not see the UAE records. The role is the same; the attributes decide the outcome. That conditional, data-dependent control is exactly what RBAC alone cannot express.

ABAC is more powerful and more complex. It shines where access must be dynamic and fine-grained — country-based data residency, hospital-based patient access, project-based visibility. The trade-off is administration: attributes and policies to maintain rather than a handful of roles.

The one-line distinction: RBAC is role → permission; ABAC is attributes → policy → permission. RBAC asks "what role do you have?"; ABAC asks "what attributes apply?" RBAC is simpler, lower flexibility, best for standard access; ABAC is more complex, higher flexibility, best for dynamic and conditional access.

A common mistake is to describe them as "RBAC is table security and ABAC is row security." That is wrong. Both are access-control models — ways of deciding who gets access. Row-level and column-level security are enforcement mechanisms — ways of applying that decision to the data. The two ideas operate at different layers and combine.

The other mistake is treating them as alternatives to your governance platform. In Unity Catalog (or any governed lakehouse), RBAC and ABAC are how you express policy; the platform is what enforces it, with lineage and audit over the top.

In a mature enterprise, you combine them. RBAC handles the broad grant; ABAC adds the conditional filter. A Finance Analyst (role) can SELECT the Finance Gold tables (RBAC) — and an attribute policy then restricts them to rows where the record’s country matches the user’s country (ABAC). The final access decision is role plus attributes: Finance Analyst + country = UAE → Finance Gold, UAE rows only.

A healthcare example makes it concrete. RBAC gives Doctors access to clinical data, Finance to finance data, Operations to operations data. ABAC then adds: a doctor sees only patients belonging to their assigned hospital, by matching the user’s hospital attribute to the patient’s. A Dubai Hospital doctor does not see an Abu Dhabi patient’s record, even though both are "Doctors."

This layering is the norm for regulated, multi-region or multi-entity enterprises. Roles keep the model simple where access is uniform; attributes handle the cases where it must depend on who, what and where.

Row-level security (RLS) controls which rows a user sees — the mechanism behind "only your country" or "only your hospital." Column-level security (CLS) and masking control which columns they see or in what form — full Emirates ID for compliance, masked for analysts. Dynamic views can implement these rules where appropriate. These are how the RBAC and ABAC decisions actually take effect on the data.

The principle that matters: enforce as close to the governed data layer as possible. If RLS and CLS live in the platform, every downstream consumer — BI, a natural-language tool, an application — inherits the same controls. Push security into each report instead and you get inconsistency and gaps, and every new consumer re-implements it, usually differently.

So the stack reads: identity and groups (RBAC) plus attribute policies (ABAC) decide access; RLS, CLS and masking enforce it at the data; lineage and audit prove it. That is the shape of governed access in an enterprise lakehouse.

If asked to explain the difference: RBAC controls access based on predefined roles or groups; ABAC decides access based on attributes of the user, resource or context. RBAC is simpler and works for standard organisational permissions; ABAC provides dynamic, fine-grained policy control. In an enterprise lakehouse you use the platform’s governance together with groups, privileges and attribute-based policies, enforced through row- and column-level security, according to the organisation’s requirements.

The practical guidance: start with RBAC and groups for the bulk of access, add ABAC where the business genuinely needs conditional rules (residency, multi-entity, clearance), and enforce everything at the data layer with RLS and CLS. Do not over-engineer ABAC where a role would do; do not stretch RBAC to express conditions it cannot.

Whatever the platform, the model is the same. We apply this on Microsoft Fabric and Power BI and on Databricks Unity Catalog alike — the access-control models and enforcement mechanisms are universal; only the syntax differs.