Row-Level Security (RLS) is the data governance control that automatically filters which rows from a table are visible to a given user based on that user's identity or attributes. Like column-level security, RLS is enforced at query time by the query engine, not by physical data partitioning. This allows a single shared Iceberg table to serve multiple user populations, each seeing only their authorized subset of data.
Classic Row-Level Security Scenarios
- Regional Data Isolation: A global sales table contains data for all regions. Regional managers can only see rows where region = their assigned region. The same table serves all regional managers, each with a different automatic row filter applied.
- Tenant Isolation in SaaS Analytics: A multi-tenant analytics platform stores all customer data in shared Iceberg tables. RLS ensures that when Tenant A's user queries the table, they only see rows where tenant_id = their tenant. Complete data isolation is achieved without separate physical tables per tenant.
- Employee Data Confidentiality: An HR analytics table contains all employees. Managers can only see rows for employees who directly report to them, automatically applied based on the manager's user attribute.
RLS Implementation in Dremio
Dremio implements row-level security through row filter policies defined at the VDS (Virtual Dataset) level. A policy expression like WHERE region = SESSION_USER_ATTRIBUTE('region') is automatically injected into every query against the dataset. The user never writes the WHERE clause themselves; it is transparently enforced by the engine based on the authenticated user's identity context from the SSO provider. This means users cannot bypass RLS by writing their own SQL, since the filter is applied before query planning completes.
