Looker Data Masking
You set up looker data masking by linking user attributes to conditional model expressions. These expressions check user roles and rewrite matched fields like emails in query results. Teams often build these rules inside the reporting layer to protect sensitive columns. Still, broad database roles still expose raw tables to anyone querying outside the app. How looker data masking works in the semantic layer Looker does not store your company data inside its own servers. Instead, it builds SQL
Data Masking (Static): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up looker data masking by linking user attributes to conditional model expressions. These expressions check user roles and rewrite matched fields like emails in query results. Teams often build these rules inside the reporting layer to protect sensitive columns. Still, broad database roles still expose raw tables to anyone querying outside the app.
How looker data masking works in the semantic layer
Looker does not store your company data inside its own servers. Instead, it builds SQL queries on the fly based on a modeling layer. Admins define user attributes and assign them to specific groups or individual people. Then, developers write conditional logic inside the model definition for each sensitive column.
When a person runs a report, the platform checks their assigned user attribute first. If the user holds the right attribute, the query fetches the actual column value. If the user lacks that attribute, the platform changes the generated SQL query. It replaces the real column with a fixed string or a hash value.
This approach works well for fields like phone numbers, card numbers, and national IDs. Analysts still see the row count and can group records by other attributes. Masking rewrites matched fields in results while keeping the dashboard layout intact. Report builders do not need to create two separate views for different teams.
What semantic layer rules solve and what they miss
Semantic layer rules help teams share one dashboard across many business units. Support staff and finance analysts can open the exact same report link. Each person sees only the level of detail that fits their role. This saves time because data teams maintain one central set of charts.
Still, semantic rules only control queries that pass through the charting app. The BI tool itself often uses a single shared service account for database logins. That service account needs broad read permissions on the underlying database tables. Anyone who can run raw SQL inside the tool might bypass model rules.
Data Masking (Static): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Engineers and data scientists also query the database using their own local SQL clients. Those direct database sessions do not read the BI modeling layer at all. A rule written in the reporting app has zero effect on a terminal session. Teams end up copying the same masking logic into multiple places.
Why managing rules across multiple tools gets hard
When teams grow, they add more tools for notebooks, scripts, and ad-hoc queries. Keeping user attributes synced between the BI app and the database takes constant work. If an admin forgets to update one role, a table might leak raw emails. Audits become slow because reviewers must check both model files and database grants.
Database views can enforce masking closer to the storage engine, but they add friction. Every new sensitive column requires a migration and updates to downstream view definitions. Also, static role grants decide who logs in, not what individual statements do in flight. Teams need a simpler way to inspect queries and mask fields in real time.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does looker data masking change the underlying database table?
No, it only changes the SQL query that the BI tool sends out. The raw data inside your database table stays untouched in its original form. Masking rewrites matched fields in results only when the report runs.
Can users bypass model masking through the SQL Runner tool?
Yes, if a user has permission to run raw queries in the SQL tool. Those queries go straight to the database using the shared connection credentials. They skip the semantic modeling layer where the conditional masking logic lives.
Which fields should teams mask first in business reports?
Start with common personal identifiers like emails, phone numbers, card numbers, and national IDs. Most chart viewers only need totals and trends, not raw contact details. Rewriting these specific columns reduces risk during daily report sharing.