Permission Management

On this Page
Docs Menu

When it comes to permission and access controls in Looker, it’s helpful to think of two different categories of controls:

  • Controlling what a user is allowed to do within Looker, and which data they can access
  • Controlling what content (Looks and dashboards) a user is allowed to see and edit

While these two systems can overlap, each can also be adjusted independently of the other.

For users with access to multiple models, the way Looker displays content is changing in Looker 4.10 and 4.14. Users won’t be able to query more information than they could before, but they may be able to see Look and dashboard titles that were previously hidden to them. Users who can already view all Looks and Dashboards in a Space or sub-Space will not be affected by these changes. For a more detailed description, please see this article.

Users and Groups

In Looker there are both individual users and groups of users. Users are managed on the Users page of Looker’s Admin panel, while groups are managed on the Groups page of Looker’s Admin panel.

All controls can be applied to individual users, and most can also be assigned using groups. In general, we suggest that you work with groups when you can, because you’ll be able to avoid the tedium of assigning controls to lots of users individually.

Controlling User Abilities and Data Access

To control user abilities and data access in Looker you’ll usually create a group of users (this is optional, but suggested) and assign that group to a Role. A Role ties together a set of permissions with a set of LookML models. The models themselves define which fields and data is available.

You might also consider making use of “access filter fields” which are used to apply specific data limits to specific users. And, you can limit developers to particular databases by using projects.

It breaks down like this:

If you want to achieve this … These are the basic steps you’ll take …
Control the actions a user can perform Create a permission set with the appropriate permissions, then assign a group or user to a Role with that permission set
Control what fields a user can access Create a model with the appropriate fields, then assign a group or user to a Role with that model
Control what data a user can access Create a model with the appropriate data limitations, then assign a group or user to a Role with that model

- or -

Use access filters to limit a user to the appropriate data

- or -

Use user attributes to provide differing database credentials to a group or user
Control what database connections a developer can access Create a project with the appropriate connections, associate the project with a set of models, then assign a group or user to a Role with those models

Building Blocks You’ll Need to Understand

Roles

A Role is a combination of one permission set, and one model set. The permission set defines what the Role may do, and the model set defines which LookML models the Role may see.

After you create a Role you can assign an individual user, or a group of users, to that role. If you add some Roles to an individual user, and other Roles to a group that the user belongs to, the user will inherit all of those Roles put together.

Some permissions are relevant to your entire Looker instance, while others only apply to the models within the same Role. These details are described on our Roles page.

Projects

Projects allow you to restrict which database connections may be used by which models. This can help you control which sets of data your Looker developers can interact with when they are creating models.

These permissions also flow through to the Looker SQL Runner, which ensures that your developers cannot get access to prohibited databases by using the SQL Runner.

User Attributes

User attributes allow you to assign arbitrary values to groups of users or individual users. These values can then be used as inputs to various parts of Looker, allowing you to customize experiences for each user.

In terms of permissioning, the most important functions of user attributes are:

  1. The ability to parameterize your database credentials to be specific to each user. This will only have value if your database is configured with multiple users of varying data access.
  2. The ability to utilize user attributes as part of an access filter, which is described next.

Access Filters

Access filters allow you to utilize one or more user attributes as a data filter. For example, you might want to give each user a company name, then make sure any content they see is filtered by that name. They’re described in more detail on the access_filter page.

Using the Building Blocks

Control User Abilities

The abilities that a user has are controlled by the permissions that they have. This is how a user can get permissions:

  1. Create a permission set that contains the appropriate permissions, then assign it to a Role. This is done on the Looker Roles page.
  2. If you want to work with groups of users, which is usually our suggestion, create a group on the Looker Groups page. Then assign that group to the appropriate Roles on the Roles page.
  3. If you want to work with individual users, assign Roles to those users from either the Users page or the Roles page.

You can assign multiple Roles to a user or group. In that case, users will have all of the permissions from all of the Roles they have.

Control User Access to Looker Fields

The fields that a user can work with are controlled by the models they can access. This is how a user can get field access:

  1. Create a LookML model (or combination of LookML models) that contain only the fields a user should have access to.
  2. Create a model set that contains those models, then assign it to a Role. This is done on the Looker Roles page.
  3. If you want to work with groups of users, which is usually our suggestion, create a group on the Looker Groups page. Then assign that group to the appropriate Roles on the Roles page.
  4. If you want to work with individual users, assign Roles to those users from either the Users page or the Roles page.

You can assign multiple Roles to a user or group. In that case, users will be able to work with all of the models from all of the Roles they have.

It’s important to note that the hidden parameter is designed to create cleaner experiences for users, not for controlling field access. The hidden parameter hides fields from the field picker, but it won’t prevent a user from ever using that field. If someone sends them a link that uses that field they will be able to see it, and there are other places in Looker that will still show the field.

Control User Access to Data

There are several ways to control a user’s access to data, depending on the use case:

  • If you want to prohibit users from seeing certain columns of data you’ll do so by controlling the fields they can access. This procedure was described just above. As long as a user cannot develop, and cannot use the SQL Runner, they are constrained by the fields they have access to.
  • If you want to prohibit users from seeing certain rows of data you’ll do so by applying access filter fields. The instructions for doing so are described on the access_filter page.
  • If you want to limit Looker users to running queries on a specific database user, which your database team has configured to limit data access, you can use user attributes. They allow you to parameterize your database connection so that a group of users or individual users run their queries with specific database credentials. If you go this route, you should consider limiting users to the proper Looker fields as well. If you don’t, the Looker user may try to query a field that their database user doesn’t have access to, and they’ll receive an error.

Control Developer Access to Database Connections

Unlike regular users, developers are not fully constrained by models and access filters, because they can simply make additions or changes to LookML models. However, administrators can still limit developers to certain database connections by using projects. To do so:

  1. Create a project that restricts a certain number of models to a certain number of database connections. This is done on the Looker Manage Projects page.
  2. Create a model set that contains at least one of the models in the project, then assign it to a Role. This is done on the Looker Roles page.
  3. If you want to work with groups of users, which is usually our suggestion, create a group on the Looker Groups page. Then assign that group to the appropriate Roles on the Roles page.
  4. If you want to work with individual users, assign Roles to those users from either the Users page or the Roles page.

Please note that if a developer can see any model that is part of a project, they will be able to view all models that are a part of that project. For example, this could happen if you assigned a developer to a Role with only one model, but that model happened to be a part of a project that contained other models.

Controlling User Content Access

Looker Spaces are essentially folders that you can use to organize sets of dashboards and Looks. They can also contain other Spaces, allowing for a nested hierarchy of organization.

Spaces let you set which users may edit its contents (such as Looks and dashboards), view its contents, and change its settings.

Spaces do not control what users can do on the Looker platform, or which data they can use to build their own content. To manage that level of access, check out our Controlling User Abilities and Data Access section above.

The step-by-step instructions for adjusting Space permissions are discussed on our Organizing with Spaces page.

Making Use of Your User Permission Infrastructure (LDAP and SAML)

If you already have an LDAP or SAML infrastructure setup, you can use that system to manage user logins. The instructions for setting up LDAP can be found here, while SAML is here.

If you’ve configured groups in your LDAP / SAML implementation, you can also use those groups within Looker. However, there are a few things to keep in mind:

  • Any groups you’ve created will automatically be transferred into Looker, and will be visible on the Groups page.
  • You’ll be able to use these Looker groups for Spaces access control. However, you will not be able to use them to configure Roles like you would with a manually created group.
  • Instead, you’ll map your LDAP / SAML groups to Looker Roles during the LDAP / SAML setup process, and will only be able to change this setting from the LDAP / SAML setup pages. We’ve required this approach so that your LDAP / SAML groups remain your single source of truth. Without this restriction, group to Role mapping could diverge from their intended function in your LDAP / SAML scheme.

Furthermore, you may use LDAP to apply user-specific database connections to Looker queries. The considerations involved in implementing this feature, and the instructions for doing so, are discussed in this Discourse post.

Still have questions?
Go to Discourse - or - Email Support
Top