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 best judgment when implementing.
- Configure secure access between the Looker application and your database. Looker documentation provides several recommendations on how to do this, including whitelisting Looker IPs, SSL Encryption, and connecting to databases via SSH tunnel.
- Set up the most locked-down database account permissions for Looker that will still allow the application for perform all needed functions. Check our documentation for your database setup for needed privileges.
- Set up user authentication using either 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 into Looker.
- Never post API credentials publicly. API credentials should be stored as environmental variables when possible, and never 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:
- Set up the most restrictive user permissions and content access that still allow people 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 article Secure your Spaces! A Content Access Walk-through
- Use the access_filter parameter in conjunction with user attributes for applying row-level data security by user or user group.
- Use model sets for applying data set security within the Looker model. Uses will be unable to see any content outside of their assigned model set.
- Avoid assigning users to roles individually whenever possible. Users given individual roles and roles based on group membership will inherit all roles from both the individual and group assignments. This can result in user accumulating permissions beyond what they should have. The best practice is to assign roles based on group membership whenever possible.
- Most users should be Viewers of the Shared space (except in closed system setups). This ensures that users will be able to see content in the Shared spaces and any subspaces to which they have access. Providing users with Manage Access, Edit permissions on the Shared space means that they will retain those rights within any and all subspaces as well. It can be helpful to make changes lower in the tree first, and THEN revoke access higher up.
Implement the appropriate type of Looker system based on the access controls that 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 space (called “Shared”).
- For more details on setting up a completely open system, please check out our documentation.
- Open With Content Restrictions: Content needs to be locked down in some way, either so that only certain people can edit certain content or so that certain content is entirely invisible to particular people. When possible, plan for a flatter hierarchy, as this will be easier to manage than deeply nested spaces.
- For more details on setting up an open system with content restrictions, please check out our documentation.
- 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.
- For more details on setting up a closed system, please check out our documentation.
Check out our documentation for more information on Looker Access Control and Permission Management or on Designing and Configuring a System of Access Levels.