Access Control and Permission Management

On this Page
Docs Menu

At Join 2017, we’ll have a session called (Don’t) Keep It Secret; (Do) Keep It Safe by Ryan Gurney and Mike Xu. Making sure that everyone has access to the data they need while managing access and permissioning can be challenging. This session will discuss best practices for managing security.

Overview

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

  • Content Access, which controls whether a user or group of users can view a Space or manage the Space. A user who can view a space can navigate to the Space and view the lists of the dashboards and Looks in the Space. A user who can manage a Space can manipulate the contents of a Space (copying, moving, deleting, and renaming dashboards and Looks), organize the Space itself (renaming, moving, or deleting the Space), and give other users and groups access to the Space. Content access is managed by Looker admins on the Admin tab or, if allowed, by individual users from the Browse page.
  • Data Access, which controls which data a user is allowed to view. Data access is primarily managed via Model Sets, which make up one half of a Looker role. These roles are then applied to users and groups. Data access can be further restricted within a model using access filters to limit which rows of data they can see, as though there was an automatic filter on their queries.
  • Feature Access, which controls the types of actions a user is allowed to do in Looker, including viewing data and saved content, changing the LookML models, administrating Looker and so forth. Feature access is managed by Permission Sets, which make up the other half of a Looker role. Some of these permissions apply for the entire Looker instance, such as being able to see all schedules for sending data. Most of the permissions are applied to specific model sets, such as being able to see user-defined dashboards based on those models.

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:

  • 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.

  • 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, re-naming and moving spaces, and similar actions.

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 page. Looker admins can also adjust Space access levels for all groups and users from the Content Access page.

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 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 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 access, 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 Feature Access

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

  1. Best practice is to identify one or more groups of users that should have that 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.

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.

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 role(s) assigned to a user determines 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:

  • Even if the user can see a Look listed in a Space and can navigate to the Look, the Look’s query is not run and the user can’t see the Look’s data.
  • Even if the user can see a dashboard listed in a Space and can navigate to the dashboard, any tile where the user doesn’t have access is displayed as blank. If a dashboard that has tiles created from multiple models, a user will be able to see the tiles associated with models they have access to, and the tiles from other models will be blank.

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, re-naming 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 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 on the LDAP page. The instructions for setting up SAML is in this discourse article.

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. One Looker group will be created for each LDAP / SAML group, and the Looker group name will mirror the LDAP / SAML group name.
  • You’ll be able to use these Looker groups to assign Spaces access control and user attributes to members of the groups.
  • You will not be able to use Looker groups 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 assigned roles 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 article.

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