Looker Non-Embed Content and Data Management Solutions: A (Use) Case Study

Source: Thinkstock

Looker provides several access control tools for administrators who must ensure data access is configured and managed properly to meet their business and security needs. Those tools include:

• Access filters: apply row-level security to your data.
• Access grants: apply object-level security to your LookML.
• Content control: apply access security controls to Dashboards and Looks in your instance.

At 4 Mile, we’ve helped many of our clients set up robust access controls that meet their specific security requirements. This blog post is intended to synthesize and share our experiences by introducing common use cases and providing access control solutions that meet each use case.

The following use cases apply to non-Embed solutions (i.e. all Looker users will access and view data within the Looker web application). Here are some potential solutions to embedding Looker into external tools and applications. 4 Mile Analytics also specializes in implementing non-embed, embed, and custom visualizations from Looker. If your team requires assistance in implementing your data solution, please let us know!

Defining Our Use Cases

Use Case A:

Tiger Queen Rentals offers tiger geolocation services to thousands of individual, certified tiger keepers across the United States. The company offers tiger keepers access to their Looker instance, where each customer can view geolocation metrics via dashboards that display data that pertain to them. Additionally, Tiger Queen’s internal customer service team will need to access those metrics across all customers to provide on-demand support.

Use Case B:

Ozark Boating Company (OBC) intends to migrate sensitive financial data from its legacy software to Looker so its executive team can view and access financial metrics. It’s paramount that the marketing and sales teams currently utilizing Looker do not have access to this data. Most of the busy, less technically-savvy executive team has requested quick and easy access to the financials Explores and Dashboards that pertain to them. The inquisitive CTO, however, requested to have access to all content in the Looker instance.

Groups:

Groups help manage content access for users within your Looker instance. For most use cases, it’s best practice to categorize users into groups based on the content that pertains to them. To manage user groups, navigate to Admin > Groups.

Use Case A:

Since external and internal users will be accessing Looker, the Looker Admin should create ‘External’ and ‘Internal’ groups to effectively categorize the external customers and the internal customer service team.

Use Case B:

The Looker Admin should assign users on the Executive team to the new ‘Executive’ group. This will help set up a clean way to separate them from Looker users on the marketing and sales teams. To accommodate the CTO’s request, create an ‘All Access’ group.

User Attributes

User attributes are essentially key-value pairs associated with each user’s profile and can be used to ensure data is accessed properly (access_filters and access_grants). To manage user groups navigate to Admin > User Attributes.

Use Case A:

The goals are (1) to apply record-level security for Tiger Queen’s external customers to ensure data displayed in Looker content only pertains to them, while (2) granting full data access to internal customer service Looker users so they can provide support to any customer.

To achieve these two goals, the Looker Admin should:

1. Create a user attribute called ‘tiger_company’ with type: advanced_filter_string where the user attribute value successfully links each tiger company customer to the associated view rows via a LookML dimension within the explore (see the Data Access section below).
2. Populate ‘tiger_company’ user attribute value with ‘%’ or ‘%, NULL’ for each internal customer service user profile so to grant access to all customer data. This user attribute can and should be managed on the ‘Internal’ group level.
3. Apply an access_filter to the relevant Explores to link each ‘tiger_company’ user attribute value to each row via a fully-scoped field in the model.

Separating internal and external facing LookML: 4 Mile also recommends separating external and internal LookML into separate model sets, as it’s easier to maintain and harder to make access related mistakes. To avoid duplicating LookML across your external and internal models, the Looker developer can extend those explores from the external model into their internal model as needed.

Automating user attribute assignment: It’s important to note Tiger Queen manages thousands of individual external tiger owners. Given this, managing thousands of user attribute values manually will likely trigger administrative headaches. Fear not! Find two programmatic solutions below:

• Looker API: create a microservice that leverages the Looker API to update user attribute values on the individual or group level when a new external Looker user is created.
• OpenID Connect: if your company integrated an OpenID Connect Provider (e.g. Okta) into your Looker instance, Open ID Connect can automatically provision users with their appropriate claim upon user login.

Use Case B:

The Looker Admin should utilize a ‘department’ user attribute and link the ‘executive’ user attribute value to the Executive group (under the ‘Group Values’ tab) to set up access control to the financial related LookML objects in the project.

Using the ‘all_access’ user attribute, the Looker Developer can apply an access grant ‘can_view_finanical_data’ to the relevant Explore(s) capturing financial data.

Content Access

Based on the particular security requirements, the appropriate level of content access can ensure what users can view or edit in Looker folders. When granting access to external customers, Admin users are recommended to utilize a closed system (e.g. remove the ‘All Users’ group). An open system with restrictions allows for blocking access to shared folders but doesn’t restrict view-access to content in user folders. A completely open system allows edit-access to all shared and view-access to user content.

Use Case A:

Tiger Queen will need to block internally-facing content from its external customers. To configure Tiger Queen’s instance, a Looker Admin should:

• Follow the steps here to update the Looker instance to a closed system.
• Within the Content Access page in Admin, create an ‘External’ subfolder within the Shared folder and grant view-access to both ‘External’ and ‘Internal’ groups.
• Within the Content Access page in Admin, create an Internal subfolder within the Shared folder and grant view-access to the ‘Internal’ group only.

Use Case B:

Recall most users from the OBC Executive team requested quick access to view financial data and the CTO, however, would like to view all content within the instance. To meet these requirements, the Looker Admin should configure an open system with certain restrictions. Specifically:

1. Within your Shared folder, update the All Users access from Manage Access, Edit to View. This configuration allows for applying restrictions to certain Looker users for the open content system**.
2. Within your Shared folder, create a ‘Financials’ subfolder.
3. Grant the ‘Executive’ group the view-access to the ‘Financials’ subfolder. Ensure other teams (besides Admins) do not have access to this subfolder.
4. For all other subfolders in Shared, ensure the ‘Executive’ group does not have access. Grant view-access to the ‘All Access’ group.
5. Homepage URL Update: To allow for quick access to the shared folder, update the Homepage URL by selecting the ‘A URL within Looker’ option and applying ‘/folders/home’ (Admin > Homepage). Upon login, all users will be directed to the Shared folder.

**Keep in mind since OBC is using an open system with restrictions, Executive team members will have access to view content in personal user subfolders. This access level fits OBC’s use case since this access doesn’t negatively affect the Executive team’s request for easy access to the financial related content.

Closing Remarks and Some Considerations For Your Use Case

With the available Looker security resources and the recommendations delineated above, Tiger Queen Rentals and Ozark Boating Company have successfully democratized their data while applying the appropriate content and data access controls to each instance user. The folks at 4 Mile hope the reader finds these examples useful. Below are some questions your data team can answer to help firm up your team’s Looker security requirements.

1. Where will the Looker content be displayed (Non-Embed vs. Embed)? If Dashboards and Looks are to be accessible for all users within the Looker instance, you should find this document helpful. Otherwise, find Looker Embed resources here and work with us to integrate Looker content into your desired application!
2. Who are my Looker users and how best can they be categorized based on the Looker content they should have access to? e.g. internal vs. external; individual vs. groups. Data explorers vs. dashboard viewers.
3. How many users (for each user type) will be accessing Looker? The number of users affects the Looker user management administration load. If there are many users under management, consider using user groups and programmatic tools to update user attributes.
4. Based on the data within your model and the associated security requirements, what restrictions should be applied to the data? Consider using access filters, access grants, and separate model files to secure your data effectively.