Blog
Scale Your Looker Dashboards Safely with Row-Level Security
Reading time.
5
Wrtitten by
Amélie Richioud
Business Intelligence
Introduction
Data democratization is a key goal for modern organizations. Every employee should be able to make data-driven decisions. However, this opening creates a security paradox.
So, how can we grant full access to analytics without taking the risk that, for example, an employee from a department sees the data of another department ?
The Pain Point: The “Export Gap”
The main risk is “Shadow BI”. When the security is too tight or reports are inaccessible, users export files on their desktop to work “in their own way”.
Impact is critical:
Loss of control: sensitive data like special clients or production volumes of rare models, can be exposed because of the excel files.
Exponential maintenance: without Row Level Security, data teams will waste time on duplicating the same dashboard for each geographical area or collection.
In fact, we can see that 40% of the analyst’s time is spent handling duplicate reports instead of being focused on the stocks optimization or the analysis of consumer trends.
Solution: Customized filtering
The RLS is not a basic cosmetic filter. It’s a structure where reports stay identical for all users, but with content that dynamically adapts to the identity of the viewer.
In our practice, we frequently observe clients maintaining up to 5 separate, duplicated dashboards for different regions (e.g., EMEA, AMER, APAC) or departments. By implementing Looker’s Row-Level Security, we consistently help them consolidate these redundant assets into a single, dynamic dashboard.
The technical approach: SQL ingestion in the source.
Looker is unique thanks to its capacity to filter the data before it’ll be outside of the database (e.g. Bigquery) :
User attributes
Before writing any security rule, you need a mechanism to identify who is executing the query. In Looker, this is handled through User Attributes.
A User Attribute is a key-value pair tied to a specific user or group (e.g., department = Sales or country = France). User attributes are variables linked to the user profile. These attributes can be assigned manually by administrators, synced automatically via your Identity Provider, or set dynamically using user groups.
When a user logs into Looker, their attributes act as a digital passport. LookML developers can then reference these values natively in code using the syntax {{ _user_attributes[‘attribute_name’] }}, turning static dashboards into personalized, dynamic views
Deep Dive into Native filtering (LookML)
Security in Looker does not happen in the browser or on the UI level — it happens at query generation time. This process is called Native Filtering.
When a user opens a report or runs an Explore query:
Request Interception: Looker intercepts the action and inspects the user’s active User Attributes.
SQL Injection: Looker injects dynamic conditions (WHERE or JOIN clauses) directly into the LookML SQL generation process.
Database Execution: Looker sends the secured, fully rendered SQL query down to your Data Warehouse (BigQuery, Snowflake, Databricks).
Zero Data Leakage: Because the database itself executes the query with the security filter applied, unauthorized rows are never fetched, cached, or transferred over the network.
Solution without being the administrator
A common misconception is that security requires “admin” rights across the entire Looker platform. This is not true. If you are a LookML developer, you can secure the data flow in the code.
In other words, if you don’t have access to the user management, you can use alternative filtering techniques based on the data itself:
The access_filter parameter: even if you aren’t an administrator, if some user attributes are already created by your IT team, you can call it in your “explores” to automatise the security.
Security joins: you can link your fact tables to a mapping table in LookML.
Sql_always_where parameter: it’s the most powerful tool for a developer. You can enforce an immutable SQL condition that will apply to all user queries, ensuring that no one can “uncheck” a security filter.
Why is it so important ? This means that the security becomes an integral part of the BI development cycle, rather than a burdensome administrative task.
Step-by-Step Implementation guide
How to Implement Row-Level Security in Looker: Step-by-Step
Step 1: Define the User Attributes (Admin)
Ensure your User Attributes exist in Admin > User Attributes.
Name: region_access
Type: String / User-defined
Domain Values: Set default values or assign specific values per group (e.g., Group EMEA = EMEA, Group US = US).
Step 2: Choose Your LookML Strategy
Depending on your granularity and governance needs, select one of the following methods in your LookML project:
Option A: Simple LookML Filter (access_filter)
Ideal for straightforward, single-field dynamic filters defined directly inside an Explore.
Option B: Advanced SQL Injection (sql_always_where)
Best for complex conditional logic, multi-tenant setups, or handling wildcard/admin overrides.
Option C: Security Mapping Table (Security Join)
Recommended when a single user needs access to multiple regions or when permission logic changes frequently in the data warehouse.
Step 3: Test with “Sudo” (Validation)
Never deploy RLS without testing. Navigate to Admin > Users, find a target user profile, and click Sudo. Open the Explore, run a query, and check the generated SQL in the SQL tab to ensure the WHERE clause is applied as expected.
Conclusion and recommendations
RLS transforms security: it enables the transition from reactive, siloed BI to proactive, unified BI, making it more convenient for users.
The key benefits:
Protection: respect confidentiality and the client’s privacy.
Technical agility: one data model for the company.
Scalable: add a new market or another without creating new reports.
Practical advice: Audit your current access. If your reports are manually segmented by countries or by brand, your BI architecture is in survival mode. Ask yourself: “if tomorrow I add 10 stores, how many times do I need to configure their reports ?”. The answer is: too many if I can’t use RLS properly.
We can help you
If you need to secure your data ecosystem while unlocking the potential of your analysts, contact us to discuss implementing a robust and scalable Looker architecture.
Written by
Amélie Richioud
Analytics & Insights Engineer
Download
