These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers, from implementation to long-term success. The practices are written to work for most users and situations, but — as always — use your best judgment when implementing them.

Database Security

• Configure secure access between the Looker application and your database. Looker documentation provides several recommendations, including adding Looker IPs to your allowlist, encrypting SSL transmissions, and connecting to databases via SSH tunnel.
• Set up the most locked-down database account permissions for Looker that will still allow the application to perform all needed functions. Check out the Database Configuration Instructions documentation page for database-specific setup requirements.

Product Security

• Set up user authentication, either using Looker's native username/password option or, preferably, using a more robust authentication mechanism like 2FA, LDAP, Google OAuth, or SAML. These methods are mutually exclusive and vary in security level. Google Oauth, for example, allows anyone in your email domain to log in to Looker.
• Never post API credentials publicly. API credentials should be stored as environmental variables when possible, and should never be shared over email or chat support.
• Regularly audit any public access links your users create, and restrict the permission to create them as necessary. The following i__looker Explore lists all public Looks and their creators on your Looker instance. Replace instance_name.looker.com with the URL of your Looker instance:

https://<instance_name.looker.com>/explore/i__looker/look?fields=look.id,look.title,look.public,user.name&f[look.public]=Yes&limit=500&query_timezone=America%2FLos_Angeles&vis=%7B%22type%22%3A%22table%22%7D&filter_config=%7B%22look.public%22%3A%5B%7B%22type%22%3A%22is%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22Yes%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%7D&dynamic_fields=%5B%5D&origin=share-expanded

• Those with the System Activity Model enabled on their instance (available as a Labs feature as of Looker version 6.2 and generally available in Looker 7.12) can track public Looks via the following Explore URL:

https://<instance_name.looker.com>/explore/system__activity/look?fields=look.id,look.title,look.public,user.name&f[look.public]=Yes&limit=500&query_timezone=America%2FLos_Angeles&vis=%7B%22type%22%3A%22table%22%7D&filter_config=%7B%22look.public%22%3A%5B%7B%22type%22%3A%22is%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22Yes%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%7D&dynamic_fields=%5B%5D&origin=share-expanded

• Set up the most restrictive user permissions and content access that still allow users to carry out their work, paying special attention to who has admin privileges. For a more thorough explanation of these features, please check out our Help Center article Secure your Spaces! A Content Access Walk-through. Note: As of Looker version 6.20, "Spaces" are called folders.
• Use the access_filter parameter, in conjunction with user attributes, for applying row-level data security by user or user group.
• Leverage access_grants, in conjunction with user attributes, to control access to LookML structures such as Explores, joins, views, and fields by user or group.
• Use model sets to apply data set security within the Looker model. Users will be unable to see any content outside their assigned model set.
• Avoid assigning users to roles individually whenever possible. Users who are given both individual roles and roles based on group membership inherit all roles from both the individual and the group assignments. This can result in users accumulating permissions beyond what they should have. The best practice is to assign roles based only on group membership whenever possible.
• Most users should be Viewers of the Shared folder (except in closed system setups). This ensures that users will be able to see content in the Shared folders and any subfolders to which they have access. Providing users with Manage Access and Edit permissions on the Shared folder means that they will retain those rights within any and all subfolders as well. It can be helpful to make changes lower in the tree first, and THEN revoke access higher up. This is discussed in greater detail below.

Content Security

Implement the appropriate type of Looker system based on the access controls you need to support:

• Completely Open: There are no limits to who can see and edit items within the system. The All Users group should be assigned to Manage Access, Edit within the root folder (called Shared). More information about enabling a completely open access system can be found on the Configuring a Completely Open System documentation page.
• Open with Content Restrictions: Content needs to be locked down in some way, either so only certain people can edit certain content, or so certain content is entirely invisible to particular people. When possible, plan for a flatter hierarchy, as this is easier to manage than deeply nested folders. For more details on setting up an open system with content restrictions, please check out the Configuring an Open System with Restrictions documentation page.
• Closed System: This system completely separates content across groups, preventing users from different groups from even knowing about the others. A closed system is best for multi-tenant Looker installations. Please make sure to read the closed system documentation page before pursuing this option. Once a closed system is enabled, it is difficult to change Folder Management access. This documentation page provides more information about enabling a setup for a Looker instance.

Check out our documentation for more information on Looker Access Control and Permission Management or on Designing and Configuring a System of Access Levels.