Optimizing Permissions with OneLake Security ReadWrite Access
Many data teams face the same challenge: balancing the need for open collaboration with the responsibility of protecting sensitive information. As organizations grow, data often lives across multiple domains—some containing critical or confidential datasets—while partner teams may only need access to a subset of that information.
Until recently, maintaining this balance often meant trade-offs. Teams had to choose between a fragmented storage setup or overexposing data just to keep their workflows running smoothly.
As a data and insights platform within Microsoft, we faced the same challenges of managing collaboration on a single Lakehouse. We process and report data across domains, with some of it being sensitive in nature and exposure should be minimized. With the public preview of ReadWrite permissions, we’ve been able to address this, and it’s changed the way we govern our data. Below is an example architecture based on our production implementation.
Consolidated Access Model
We can solve for a consolidated access model with a single Lakehouse by utilizing three broad security groups: Reader, Contributor, and Restricted.
Contributor: reserved for engineers who need full access to data across the entire Lakehouse. They can read and write with these schemas at will.
Reader: reserved for business users who, after going through proper access reviews, can read cooked data.
Restricted: reserved for engineers who don’t need access to sensitive data but still need to interact with a subset of the data in the Lakehouse. Users in the Restricted security group are able to read and write data from Schema B but cannot see or interact with data in Schema A.
Real-Life Production Scenario
The following is an example of our production storage workspace. In it, we have various storage solutions that cater to different scenarios. The Unified Lakehouse is where all of our major business scenarios are output, and delineation between sensitive data must be upheld with security roles.
Within the Unified Lakehouse we have multiple schemas that serve different purposes during our data lifecycle. Curate is used for staged data while Dataprod is used for cooked dimensions and facts. The Tabular schema is the final output used in our semantic models.
Referencing the diagram at the beginning, here we can see that the Restricted role has ReadWrite permissions only on the Curate, Dataprod and Tabular schemas—meaning they will never see or be able to interact with the Sensitive_ schemas.
In summary, the introduction of the OneLake ReadWrite role marks a significant advancement in data governance and collaboration. By enabling granular, schema-level permissions within a unified Lakehouse workspace, we’ve been able to streamline access for diverse teams—empowering contributors, business users, and restricted users to work efficiently without compromising sensitive information. This approach eliminates the need for fragmented storage setups or risky overexposure, making collaboration more secure, scalable, and manageable.
To learn more, and guidance on getting started, refer to the Table and folder security in OneLake documentation.
