Looker Security
You set up looker security by pairing permission sets with model sets inside roles. You also add user attributes to filter rows and columns for each team. Most data teams start by linking their identity provider to group accounts. Problems start when admins grant broad roles to help analysts work faster. Broad roles let too many users read sensitive tables across your databases. When a shared database login has wide rights, any bad query can pull private records. How looker security works in p
Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up looker security by pairing permission sets with model sets inside roles. You also add user attributes to filter rows and columns for each team. Most data teams start by linking their identity provider to group accounts. Problems start when admins grant broad roles to help analysts work faster. Broad roles let too many users read sensitive tables across your databases. When a shared database login has wide rights, any bad query can pull private records.
How looker security works in practice
The platform splits control into two clear parts for every user role. Model sets decide which data models and database projects a person can read. Permission sets decide what actions that person can take in the app. Some users only view dashboards, while others write and run raw queries.
Admins merge one model set and one permission set to build a role. You then assign that role to groups from your identity provider. This setup keeps daily user management simple as your company grows.
For finer control, teams use user attributes inside their data models. An attribute holds a specific value, like a sales region or a department code. When a user runs a report, the app checks their assigned attribute value. It then injects that value into the query filter before sending the request. You can also use attributes to hide specific fields from certain groups. Folder rules add one more layer by controlling who views saved charts and dashboards.
Where native permissions fall short
Native roles do a good job of sorting users inside the reporting app. They control which menus appear and which saved dashboards a team can open. User attributes also work well when every person uses standard, pre-built views. Still, this setup only checks who logs into the front door.
The platform often talks to your database using one shared service account. That single database account needs wide read rights to serve every team. If an analyst gets SQL runner rights, they bypass model filters right away. Their queries run with the full power of that shared database login.
Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static roles also fail to inspect what a query returns in real time. If a table holds emails, phone numbers, or card numbers, the query pulls them. Admins must update model files by hand every time a new column appears. When someone exports a huge table or runs a risky query, no live check stops it. Plus, database logs only show the shared service account, not the actual user.
Steps to tighten analytics data controls
Start by shrinking who can write raw SQL or edit model files. Give most staff viewer roles and keep developer roles for a tiny group. Next, break large model sets into smaller pieces based on business units. Finance models should sit in a separate set from marketing or support models.
Split your database service accounts so each model uses its own database login. That way, a marketing model cannot read finance tables at the database level. Review user attributes every quarter to make sure staff moves did not leave old rights behind. Finally, pair your app rules with runtime checks that mask emails and national IDs in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do roles link to database tables in this setup?
A role pairs a permission set with a specific model set. The model set points to project files that define which database tables users can query.
Can user attributes stop raw SQL queries from reading private rows?
No, user attributes only filter queries that run through modeled views. Users with raw SQL rights talk straight to the database using the shared login.
What is the safest way to handle sensitive columns like card numbers?
Keep raw card numbers, emails, and phone numbers out of general analytics views. Use runtime masking to rewrite matched fields in results before users read them.