Looker Security: Roles, Connection Credentials, API Keys and Embedding

Looker sits between business users and the data warehouse, usually connected with a single powerful database credential, so a loose role, a leaked API key or an exposed embed secret can open far more data than any one user should see. Looker's security model is built from roles (a permission set plus a model set), user attributes, LookML access filters, per-connection authentication settings, per-user API keys, and signed or cookieless embedding. Each layer has documented edge cases that catch teams out: access filters that do not apply to Explores you forget, editable user attributes, and embed secrets that let a server mint sessions with any permissions. This guide explains how those layers work, how to configure them, what to log and how to harden an instance. It is for data platform owners, Looker administrators, security engineers and auditors. Warehouse-side controls are covered in the BigQuery Security Guide.

This is an independent guide from NHI Mgmt Group, based on Looker's public documentation as of November 2026. It is not sponsored or reviewed by Looker. Product features change, so confirm settings against Looker's current documentation.

Key takeaways

• A role is a permission set plus a model set. Instance-wide permissions such as manage_models apply everywhere if any role grants them, while model-specific permissions such as access_data apply only to the models in that role.
• Row-level security is per Explore. access_filter must be declared on every Explore that needs it; an Explore without one returns unrestricted data.
• The connection credential is the ceiling. A shared database account can read whatever the database grants it; OAuth or per-user credentials push enforcement back to the warehouse.
• API keys carry their owner's permissions. Each client ID and secret acts as the user who created it, so keys belong on dedicated API-only service accounts with narrow roles.
• The embed secret is an identity factory. Whoever holds it can sign URLs that create embed users with any permissions, models and access filters, so keep signing on the server and rotate the secret like a root credential.

How identity and access work in Looker

Looker recognises four account types: standard users who sign in through Looker or an external identity provider, embed users created by signed or cookieless embedding, API-only service accounts authenticated with API keys, and Looker Support users. Users managed by SAML, OpenID Connect or LDAP are locked on the Users page, and when the identity provider configuration disables direct role assignment, roles come from mapped groups. Google recommends enabling the Closed System option before granting access to external users.

Roles, permission sets and model sets

New instances ship with Admin, Developer, User and Viewer roles, plus Admin via IAM on Looker (Google Cloud core), a Gemini role, Looker CI Users, Conversational Analytics roles and Support roles that can only be assigned to support access users. The Developer permission set includes develop, access_data, explore, see_lookml, see_sql, use_sql_runner, deploy, download_without_limit and see_user_dashboards, which together give a developer broad visibility of data and other users' content. Two compatibility rules matter: a permission set with both develop and manage_models must be paired with the All model set, and a set with manage_modelsets_restricted cannot be. Google also warns that holding multiple roles can have unexpected effects, including downloading data from dashboard tiles without download permission, so test combined roles rather than assuming they intersect.

User attributes and access filters

• access_filter: placed in an explore block with a fully scoped field (customer.name, not name) and a user_attribute. It adds a condition to the generated WHERE clause. Each Explore needs its own; omit it and the data is not restricted.
• Missing values fail closed: a user with no value for the referenced attribute gets an error, admins included. For users who need all rows, Google suggests an advanced String Filter value such as %, NULL rather than removing the filter.
• Access level: attributes that drive access filters must use User Access None (recommended) or View. Editable attributes cannot drive them, because users could set their own scope.
• Precedence: a value set directly on a user overrides group values; among groups the configured order decides. Review direct assignments, because they silently override group-based policy.
• Verify the SQL: Google advises checking the generated SQL to confirm the filter is applied.

Admin roles and privileged access

Treat these permissions as privileged and grant them to named people through groups mapped from your identity provider.

• LookML is policy: because access filters and model sets live in LookML, deploy rights are security rights. Require pull request review on the LookML repository before production deploy. The Looker CI Users role exists for continuous integration runs; scope it to CI.
• Lockout protection: the Admin role edit page prevents the signed-in administrator removing their own admin access, except when admin access is synchronised from Google Cloud IAM.
• Disable rather than delete: disabling a user stops sign-in and keeps their content; deleting moves personal Looks and dashboards to Trash. Disable leavers on the same day through identity provider deprovisioning. See the SAML Security Guide for federation hardening.

Integrations, API tokens and service accounts

Database connections

Connection authentication options depend on the dialect. Google documents OAuth for BigQuery, Snowflake, Trino and Databricks, where each user signs in to the database and queries run as that user; a service account as the alternative for BigQuery; and a database account (username and password) for Snowflake, Trino and Databricks and other dialects.

• Hide credential values: when user attributes hold passwords, enable Hide Values (it cannot be turned off) and set a domain allowlist so the value can only be delivered to approved database hosts. The allowlist can only be tightened once values exist.
• Scope the database account: grant the Looker service account read access only to the schemas modelled in LookML, plus a scratch schema for PDTs. See the Database Credential and Access Security Guide.
• JDBC parameters: Looker enforces a per-dialect allowlist of additional JDBC parameters; keep TLS settings on and avoid parameters that weaken certificate checking.
• SSH tunnels: available on Kubernetes-based instances when enabled; manage tunnel keys as non-human credentials with an owner.

API keys and service accounts

Looker API keys are a client ID and client secret that carry the permissions of the account that created them. Administrators cannot create keys for standard users; they allow or block each user's ability to manage their own keys and can view client IDs but not secrets. For automation, Google documents API-only service accounts whose keys administrators create on the Edit User page; these accounts cannot sign in to the UI. Two version changes affect governance: from Looker 25.18 administrators can no longer manage users' keys on Looker (Google Cloud core), and Google states that from 26.8 Looker (original) administrators lose access to standard users' API credentials while still controlling who may hold them. Practical rules:

• Prefer service accounts: run integrations, schedulers and scripts as API-only service accounts with a dedicated narrow role, never a person's admin account.
• Restrict self-service keys: block key management for users who do not need the API, and review the System Activity fields Can Manage API3 Creds and Has API Credentials.
• Store secrets properly: keep client secrets in a secrets manager and rotate by creating a new key, switching the integration, then deleting the old key. See the API Key Management Guide.

Signed and cookieless embedding

An administrator enables embedding under Admin, Platform, Embed, adds the host application to the Embedded Domain Allowlist and generates an embed secret (and, for cookieless embedding, a JWT secret used internally). Signed URLs carry parameters including nonce, time, session_length, external_user_id, permissions, models, group_ids, user_attributes, access_filters and force_logout_login, signed with the embed secret; Google's reference helper code signs them with HMAC-SHA1. Each signed URL defines an Embedded Role from its permissions and models, which is additive to the roles of any groups named in group_ids.

• Sign only on the server: the embed secret must never reach a browser or mobile app. Google's Embed SDK design calls a backend endpoint that signs a URL unique to the requesting, already authenticated user.
• Derive permissions server-side: build permissions, models and user_attributes from your application's own authorisation data, never from request parameters the browser controls.
• Keep embed users minimal: grant access_data and see_user_dashboards only where needed, use user_attributes to drive access filters, and give each tenant a distinct external_user_id and external_group_id.
• Cookieless sessions: the session_reference_token must stay on the server; the authentication token is one-time with a 30-second lifespan.
• Rotate: treat the embed secret like a root credential with a named owner and a rotation procedure, and rotate immediately if it may have leaked.

Logging and detection

System Activity Explores record saved content, user and query history and instance performance. Administrators can see them by default; others need see_system_activity, and embed users cannot render system data. Retention is subject to system constraints; Elite System Activity raises limits (standard on Enterprise and Embed editions of Looker (Google Cloud core)). For long-term evidence, query the system__activity model through the API or schedule deliveries to your own store.

Pair Looker logs with the warehouse's own audit logs: with a shared connection credential, the warehouse sees one identity, so Looker's History is the only record of who ran a query.

Metrics:

• Share of Explores on sensitive models with an access_filter, checked in LookML review.
• Number of users holding Admin, deploy or download_without_limit, trended monthly.
• API keys held by standard users versus service accounts.
• Age of the embed secret and of service account keys against your rotation period.
• Users with direct user attribute values overriding group values.

Hardening baseline

1. Federate sign-in: use SAML or OpenID Connect (or Google Cloud IAM on core), map roles from identity provider groups and disable direct role assignment.
2. Rebuild roles: create custom permission sets for viewers, explorers, analysts and developers; remove see_sql, use_sql_runner and download_without_limit from anyone who does not need them.
3. Close the system: enable Closed System before onboarding external or embed users.
4. Apply access filters: add access_filter to every Explore over sensitive tables, drive it from None or View attributes, and add LookML CI checks that fail when a sensitive Explore has no access_filter.
5. Tighten connections: move to OAuth where the dialect supports it and the use case allows; otherwise scope the service account to modelled schemas and hide credential attributes with an allowlist.
6. Move automation to service accounts and block self-service API keys by default.
7. Secure embedding: server-side signing, a strict Embedded Domain Allowlist, minimal embed permissions and a documented secret rotation.
8. Export audit data from System Activity to long-term storage and review it monthly.

Testing and rollback: trial new roles and access filters on a test group and use sudo as the user (available to administrators) to confirm what a user sees before switching production groups. Keep LookML changes in Git so a broken access filter can be reverted by redeploying the previous commit.

Small versus large estates: a single analytics team can rely on default roles with adjusted permission sets and one service account connection. Multi-tenant embedding or regulated data calls for OAuth or per-user credentials, mandatory access filters and separate models per sensitivity tier.

Common misconfigurations

• Access filter on one Explore, not its siblings: a second Explore over the same view without access_filter exposes every row.
• Editable or user-level attribute overrides: direct values on users override group policy and are easy to forget during reviews.
• Everyone is a Developer: the default Developer set includes see_sql, use_sql_runner and download_without_limit, which bypass the curated experience.
• Admin keys in scripts: API keys created on an administrator's personal account give integrations full instance control and outlive the person.
• Embed secret in client code: a secret in a front end bundle or repository lets anyone create embed sessions with chosen permissions and access filters.
• Over-privileged connection account: a warehouse account with access beyond the modelled schemas turns SQL Runner and any LookML mistake into wider exposure.

Framework mapping

Practitioner checklist

• Map Looker roles from identity provider groups and disable direct role assignment.
• Remove see_sql, use_sql_runner and download_without_limit from users who do not need them.
• Add access_filter to every Explore over sensitive data and check for siblings without one.
• Set access-filter attributes to User Access None or View and audit direct user overrides.
• Enable Hide Values with a domain allowlist on any attribute holding a credential.
• Use OAuth connections where supported, or scope the connection account to modelled schemas.
• Run integrations as API-only service accounts and block self-service API keys by default.
• Sign embed URLs server-side, restrict the Embedded Domain Allowlist and rotate the embed secret.
• Enable Closed System before granting external or embed access.
• Export System Activity data and review admin, key and download activity monthly.

Standards and references

• Google Cloud: Looker Admin settings, Roles
• Google Cloud: Looker Admin settings, Users
• Google Cloud: Looker Admin settings, User attributes
• Google Cloud: Looker access_filter parameter
• Google Cloud: Connecting Looker to your database
• Google Cloud: Looker signed embedding
• Google Cloud: Looker System Activity pages
• Looker Open Source: Looker Embed SDK

Related NHI Mgmt Group resources: BigQuery Security Guide · Data Access Governance Guide · Database Credential and Access Security Guide · API Key Management Guide