2.4.6. OneLake Security and Data Access Roles
💡 First Principle: OneLake data access roles provide folder-level and file-level security within a lakehouse—like giving someone a key to a specific filing cabinet drawer rather than the whole office. Workspace roles and item permissions control whether you can see a lakehouse; data access roles control which folders and files you can see inside it. Without this layer, anyone with lakehouse access sees everything in it.
Scenario: A lakehouse contains both general analytics data (/Tables/sales/) and restricted HR data (/Tables/compensation/). The analytics team needs access to sales data but must not see compensation data. Workspace roles are too coarse—they grant access to the entire lakehouse. Data access roles solve this by restricting access to specific folders.
How Data Access Roles Work
Data access roles are defined on a lakehouse and grant read access to specific folders within the Tables or Files section:
Lakehouse
├── Tables/
│ ├── sales/ ← Analytics team CAN access
│ ├── products/ ← Analytics team CAN access
│ └── compensation/ ← Analytics team CANNOT access (no role granted)
└── Files/
├── raw/ ← Data engineers CAN access
└── restricted/ ← Data engineers CANNOT access
Configuring Data Access Roles
- Open the lakehouse → Manage OneLake data access
- Create a new role (e.g., "Analytics Reader")
- Define folder-level permissions (select which folders to include)
- Assign users or groups to the role
- Users see only the folders granted by their role(s)
Security Layer Interaction
Understanding how OneLake security interacts with other layers is critical:
| Layer | Controls | Scope |
|---|---|---|
| Workspace roles | Whether you can see the workspace | Entire workspace |
| Item permissions | Whether you can access a specific item | Single item |
| Data access roles | Which folders/files you see inside a lakehouse | Folders within an item |
| RLS/CLS | Which rows/columns you see in a table | Data within a table |
Key Principle: Layers are additive. A user needs workspace access (or item permission) AND appropriate data access roles AND must pass RLS/CLS filters to see specific data.
Important Behaviors
- No roles defined: All users with lakehouse access see all folders (backward compatible)
- Roles defined but user has none: User sees no folders
- Multiple roles: Union of all granted folder access
- Default role: Can be customized to grant baseline access to all users
When to Use Data Access Roles vs. Other Security
| Scenario | Use This | Why |
|---|---|---|
| Restrict folders within a lakehouse | Data access roles | Folder-level granularity |
| Restrict rows within a table | RLS | Row-level filtering |
| Hide columns from users | CLS | Column-level restriction |
| Restrict entire lakehouse access | Item permissions | Item-level control |
| Restrict all items in workspace | Workspace roles | Broadest scope |
⚠️ Exam Trap: Data access roles apply to the lakehouse item type specifically. Warehouse tables use RLS/CLS for data-level security—they don't have folder-based access roles. Questions about "restricting access to specific tables in a warehouse" require RLS or CLS, not data access roles.
⚠️ Common Pitfall: Forgetting that once you create any data access role on a lakehouse, users without a role lose access to all folders. This is a "deny by default" model—plan your roles before enabling them.
Reflection Question: An organization has a lakehouse with both public and restricted data. Currently all workspace members can see everything. What's the minimum change needed to restrict the HR folder to only HR team members?
