Looker Security Review

Looker’s access_filter parameter for row-level security only applies to the Explore it was added to, and Looker’s own documentation warns that an Explore left without one shows unfiltered data to anyone who can query it.

In Looker, row-level security is switched on one Explore at a time

A Looker role is built from two separate pieces: a permission set, which lists granular capabilities such as access_data, explore, develop, see_sql and manage_models among dozens of others, and a model set, which lists the LookML models that permission set applies to. Google’s own roles documentation is explicit that some permissions do not stay inside that model set the way an admin might expect: manage_models gives a user access to every model in every project on the instance regardless of the model set their role was built from, and develop or see_lookml, once granted for any model in a project, exposes the LookML of every other model in that same project even though the user still cannot query it. We test which permissions each role actually carries against the model set it was meant to be confined to.

Row-level security in Looker runs through the access_filter parameter, applied inside a model file to a specific Explore and tied to a user attribute value, the same role a BigQuery row access policy plays when a Looker model queries a BigQuery warehouse directly, since Looker is Google Cloud’s own business intelligence layer built to sit on top of it. Google’s own access_filter reference warns that the parameter has to be added to every Explore that needs it, and an Explore left without one returns unfiltered rows to anyone who can query it. A separate access_grant parameter restricts an Explore, join, view or field to users whose user attribute matches an allowed value, and Looker’s documentation states that wildcards or a range of values are not supported in that match for security reasons; we test both mechanisms against every Explore and field they were meant to cover, not just the ones an admin remembered to configure.

Looker offers three ways to put a dashboard inside another application: signed embedding builds a URL with an HMAC-SHA1 signature over an embed secret that carries the permissions, models, group IDs and user attributes for a synthetic embed user, private embedding authenticates a real Looker account through a Looker login, Google OAuth or OpenID Connect, and the Embed SDK wraps either method with a JavaScript API the host application can call. Google’s own signed embedding documentation confirms these embed users are synthetic identities generated by the URL itself and cannot inherit permissions from externally managed SAML groups. The client ID and secret used for the Looker API, generated for an individual user and carrying that user’s own roles, and the separate database credentials Looker holds for building persistent derived tables, which Google’s documentation shows can be routed through a dedicated PDT-only database user with its own write access, matter just as much if either one leaks. We test how each of these credentials is issued, scoped and stored.