fabric-securitylisted

# Security model ## Permission Layers (broadest to finest) 1. **Workspace roles**: Admin, Member, Contributor, Viewer 2. **Item-level permissions**: Read, ReadData, ReadAll 3. **OneLake security data access roles** (GA May 2026): lake-level RBAC — folder + row + column scopes enforced across all Fabric engines (see below) 4. **SQL granular permissions**: GRANT/DENY/REVOKE ## Key Principles - Admin/Member/Contributor roles grant full data read and bypass RLS/CLS/DDM - Use **Viewer role + SQL GRANT** for least-privilege consumer access - Sharing an item with no extra permissions → CONNECT only (can't read tables until GRANT SELECT) - "Read all data using SQL" (ReadData) → equivalent to `db_datareader` - "Read all data using Apache Spark" (ReadAll) → OneLake file access, does NOT affect SQL permissions - **RLS/CLS enforcement is mode-dependent** (changed by OneLake security GA, May 2026): - *SQL-defined* RLS/CLS (the `CREATE SECURITY POLICY` / column-GRANT surface below) is still enforced on the SQL endpoint **only** — users with Spark/OneLake access (ReadAll) bypass it. This hole is unchanged. - *OneLake-security-defined* RLS/CLS (lake-level data access roles) is enforced across **all Fabric engines** — Lakehouse, Spark notebooks, Direct Lake on OneLake, and SQL analytics endpoints switched to **User's identity access mode** are all GA. "Any security set applies to access from all engines in Fabric." SQL analytics endpoints left in **delegated-identity mode** do not hon