User Guide Getting Started Help Center Documentation Community Training
Looker
Access Control and Permission Management

Looker admins can manage what a user or group of users is allowed to see and do in Looker by specifying their:

The data access, feature access, and content access for users and groups combine to specify what they can do and see in Looker.

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.

The best practice is to use groups so you can avoid the tedium of assigning, adjusting, and removing controls for oodles of users individually. Typically the combination of activities that you want to allow for a user can be arranged by having that user belong to one or more groups. If you find yourself having a situation where no combination of groups is enough, consider creating a group with only one user, which lets you potentially expand that group to more people in the future. For access filters, consider using user attributes since you can assign user attributes to groups.

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, facilitating a nested hierarchy of organization.

Spaces let you set access levels that determine which users may edit Space contents (such as Looks and dashboards), view the contents in a Space, and change Space settings:

Spaces do not otherwise 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 Feature and Data Access section on this page.

The step-by-step instructions for adjusting Space access levels from the Browse section of Looker are discussed on our Organizing with Spaces documentation page. Looker admins can also adjust Space access levels for all groups and users from the Content Access page of Looker. You can also view the Designing and Configuring a System of Access Levels documentation page for information about instance-wide access level design.

Although content access is managed separately from feature access, the role assigned to a user can affect whether they can see Looks and dashboards listed in a Space, view a Look or dashboard, or manage a Space. A section below describes how feature access affects content access in more detail.

Controlling Feature and Data Access

To control feature and data access in Looker you’ll usually create a group of users (this is optional, but recommended) 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 filters which are used to apply specific data limits to specific users. And, you can limit developers to working with models based on 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

Feature access can also affect content access. See this section below for more details on how data access and feature access affect content access.

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 documentation page.

Projects

Projects let you 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.

This restriction defined through projects also flows through to the Looker SQL Runner, which ensures that your developers cannot get access to prohibited database connections by using the SQL Runner.

User Attributes

User attributes let you assign arbitrary values to groups of users or individual users. These values are then used as inputs to various parts of Looker, customizing experiences for each user.

One way user attributes control access is by parameterizing database credentials to be specific to each user. This only has value if your database has multiple users with varying data access. See the User Attributes documentation page for more information.

Another way user attributes control access is as part of access filters. Access filters let you utilize one or more user attributes as a data filter. For example, you might want to assign each user a company name, then make sure any content they see is filtered by that name. For a description of how to apply access filters, see the User Attributes documentation page and the access_filter documentation page.

Using the Building Blocks

Control Feature Access

Permissions control the types of activities that a user or group can do. This is how a user can get permissions:

  1. The best practice is to identify one or more groups of users that should have a permission set, creating a group if necessary. However, you can give permissions to individual users if desired.
  2. Create a permission set that contains the appropriate permissions.
  3. If some of the permissions to be assigned are model-specific, create or identify an existing model set.
  4. Create a role that combines the permission set and, if necessary, the model set.
  5. Assign the role from the Roles page. After the role exists, you also can assign the role to groups on the Groups page or to a user on the Users 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. For example:

If you assign both roles to the same group of users, then they can see dashboards on both Model1 and Model2 but only can explore on Model2.

Control User Access to Looker Fields

The fields that a user can work with are controlled by the models the user 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 are using single sign-on (SSO) embedding, be sure to configure these data access controls via the SSO embed URL.

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.

How Content Access and Permissions Interact

Content access is managed by users on the Browse tab, or managed by a Looker admin on the Content Access page in the Admin tab. The roles assigned to a user determine their feature and data access. This affects what they can do in a Space and whether they can view Looks and dashboards.

Viewing Data in Looks and Dashboards

To view a Look or dashboard’s data, the user must have at least View access to the Space where the content is stored.

Also, users must have access_data and see_looks permissions to select a Look and view its data. Similarly, users must have access_data and see_user_dashboards permissions to select a dashboard and view its data.

Finally, to see the data in a Look or dashboard tile, the user must have access to that data. Without the necessary data access:

In the following example, the user has View access for the Space, data access for the data, and both access_data and see_looks permissions so can see lists of Looks and view those Looks. The user does not have access to see LookML or user-defined dashboards so no dashboards appear in the Space.

Viewing a Space and Lists of Looks and Dashboards

A user needs at least the View access level to a Space to be able to view that Space and see the list of content stored inside that Space.

Users that also have at least see_looks permission see the titles of Looks in the Space. Similarly, users that also have at least see_user_dashboards permission will see the titles of dashboards in the space. However, this does not imply that they can view the data of the Looks or dashboards.

In the following example, the user has see_looks permission but does not have access_data permission. Thus the user can see the titles of Looks but can’t view the Look’s data. The user might or might not have the data access needed for the Look.

Users that have the access_data permission, but do not have either the see_looks or see_user_dashboards are not be able to see any Spaces or any content.

Modifying a Space

A user needs to have the Manage Access, Edit access level for a Space to be able to organize that Space, including copying and moving content, renaming and moving spaces, and similar actions. Users must also have the manage_spaces permission to create, edit, move, and delete Spaces.

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

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

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

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 Community topic.

Top