OneLake Security in Context — A Defense-in-Depth Map¶

Last Updated: 2026-05-28 | Version: 1.0.0

A practical guide to where OneLake security fits among the eight Fabric security layers. Includes a "what to use when" decision matrix, the Direct Lake fallback gotcha, and the canonical configuration vector for each layer (UI / REST / T-SQL / Bicep).

The eight layers, at a glance¶

flowchart TB
    classDef l fill:#1A237E,stroke:#fff,color:#fff
    classDef onelake fill:#1B5E20,stroke:#fff,color:#fff

    A["1. Tenant settings<br/>(Admin portal)"]:::l
    B["2. Workspace security<br/>(roles, workspace identity, tags)"]:::l
    C["3. Endpoint security<br/>(IP firewall, MPE, OAP, Private Link)"]:::l
    D["4. OneLake data plane<br/>(item / table / row / column)"]:::onelake
    E["5. Lakehouse / Warehouse<br/>(SQL grants, RLS, CLS, DDM)"]:::l
    F["6. Semantic model<br/>(RLS, OLS, fixed identity)"]:::l
    G["7. Power BI report<br/>(audiences, sharing)"]:::l
    H["8. Identity<br/>(Entra groups, SPNs, MIs, PIM)"]:::l

    A --> B --> C --> D --> E --> F --> G
    H -.-> B
    H -.-> D
    H -.-> E
    H -.-> F
    H -.-> G

OneLake security is one layer — Layer 4. It is the only layer whose rules are enforced uniformly across Spark, the SQL analytics endpoint, Direct Lake semantic models, and authorized third-party engines. Every other layer applies to one engine or one item type.

Source: Fabric end-to-end security scenario, permission model.

Layer-by-layer cheat sheet¶

Layer 1 — Tenant settings¶

REST: GET /v1/admin/tenantsettings for inventory; programmatic update is limited — most changes still live in the Admin Portal.

Layer 2 — Workspace security¶

• Roles: Admin, Member, Contributor, Viewer. Cap: 1,000 principals per workspace; groups count once. Roles in workspaces
• Workspace identity (GA): credential-free outbound auth from workspace to Azure resources. Bicep module already in this repo at infra/modules/security/workspace-identity.bicep.
• Workspace tags: governance/billing classification.
• Capacity assignment: POST /v1/workspaces/{id}/assignToCapacity.

Layer 3 — Endpoint security¶

OAP supports different allow-list mechanisms per workload — they are not interchangeable. See the matrix at OAP overview.

Layer 4 — OneLake security (the unifier)¶

This is the layer that makes the others optional in many cases. From data-access-control-model:

• Roles = Type (Grant only) + Permission (Read or ReadWrite) + Scope (table/folder/schema) + Members (Entra).
• Deny-by-default. A DefaultReader role is auto-created with virtual membership for workspace ReadAll users.
• ReadWrite cannot be combined with RLS or CLS in the same role.
• RLS is GA. ⚠️ CLS is still Preview as of April 2026.
• Cross-engine enforcement — rules flow to Spark, T-SQL endpoint (in User identity mode), Direct Lake semantic models, and authorized third-party engines.

REST: PUT /v1/workspaces/{ws}/items/{itemId}/dataAccessRoles (reference). A complete example with RLS + CLS lives in tutorials/57-databricks-better-together/notebooks/security/01_apply_defense_in_depth.py.

Layer 5 — Lakehouse / Warehouse SQL¶

• SQL endpoint security mode (sql-analytics-endpoint-onelake-security):
• User identity mode → OneLake rules govern. SQL GRANT/REVOKE is ignored.
• Delegated identity mode → SQL-native security. Shortcuts to OneLake-secured tables are blocked.
• Warehouse T-SQL controls:
• GRANT / REVOKE / DENY (object-level)
• CREATE SECURITY POLICY + inline TVF (RLS)
• GRANT SELECT ON tbl(col1, col2) (CLS)
• ALTER COLUMN ... ADD MASKED WITH (FUNCTION = '...') (DDM)
• DDM mechanics: admins always see unmasked; non-admins need explicit GRANT UNMASK.

Layer 6 — Semantic model¶

• RLS: DAX filter on role. Only restricts Viewer; Admin/Member/Contributor bypass.
• OLS: authored via Tabular Editor — table/column permission None | Read per role.
• Multi-role evaluation: within a role, INTERSECTION of object/row/column rules; across roles, UNION (RLS predicates OR-combined, CLS = set union).
• SPNs can NOT be members of model roles. Use Fixed Identity for Direct Lake refresh (service-premium-service-principal).
• TMDL: Direct Lake partitions use mode: directLake; compatibility level 1604 (direct-lake-develop).

Layer 7 — Power BI report¶

• App audiences — publish one workspace through multiple lenses.
• Workspace roles still govern report ownership/edit. RLS/OLS only restricts Viewers.

Layer 8 — Identity¶

• Prefer Entra security groups at every grant point.
• SPNs for unattended automation (REST, fabric-cicd, refresh — paired with Fixed Identity).
• Managed identities for Azure-hosted callers writing to OneLake.
• Workspace identity for Fabric → Azure outbound (Key Vault, ADLS Gen2, Event Hub).
• Wrap Fabric Admin / Capacity Admin / Tenant Admin roles in PIM.

"What do I use when?" — Decision matrix¶

Compare and contrast — OneLake vs the other layers:

• OneLake security is the only layer that follows the data. Move a table into a new lakehouse via shortcut? The roles still apply.
• Warehouse SQL controls are engine-local — anything that reads via Spark or Direct Lake doesn't see them.
• Semantic model security is viewer-only in Power BI — anyone with workspace Contributor+ bypasses RLS/OLS at the model level.
• Network controls (Layer 3) are powerful but coarse — they protect a workspace, not a row.

The Direct Lake fallback gotcha¶

Warehouse RLS / CLS on a table that backs a Direct Lake semantic model causes Power BI to silently fall back to DirectQuery for that table.

Why it matters: Direct Lake's performance promise (no import, no DAX→SQL translation, sub-second on F64) depends on running fully in VertiPaq. The moment a Warehouse security policy is involved, the engine has to translate to T-SQL and round-trip — Direct Lake → DirectQuery.

Mitigation: lift the same RLS/CLS rules up to OneLake security (Layer 4) when you want Direct Lake performance preserved. The unified enforcement covers Power BI as well as Spark and SQL.

Sources: data-warehouse/row-level-security, data-warehouse/dynamic-data-masking, direct-lake-develop.

Defense-in-depth posture summary¶

Related¶

• Tutorial walkthrough: tutorials/57-databricks-better-together/README.md
• Companion notebook: tutorials/57-databricks-better-together/notebooks/security/01_apply_defense_in_depth.py
• Feature doc — OneLake Security: docs/features/onelake-security.md
• Best practice — Identity & RBAC patterns: docs/best-practices/identity-rbac-patterns.md
• Best practice — Network security: docs/best-practices/network-security.md