The content of this article is available in Looker’s technical documentation here.
Content Access in Looker 4.10 and Looker 4.14+
Migrating from Limited Space Visibility to Content Access Controls
Looker 3.54 Release Notes
Really looking forward to this (as you know)!
I’m reading through the notes now and was wondering if in a later release it would be possible to split out the “Manage Access, Edit” permission into 2 permissions? One allowing users to add, remove, change Looks, Dashboards, and Spaces and the 2nd to add or remove users. The problem I’m seeing now is that we want to give our “Explore users” Manage Access to be able to create dashboards and looks, but they shouldn’t be allowed to decide who has access to the space. Access to the space we’d like to restrict to the Admin user.
Thoughts on this? Does that make sense?
Hi @chris.laumans - Yep, I certainly understand the request. Our intent in structuring the system was to make it as simple as possible at first, so we kept it to two access levels to reduce complexity. We are definitely open to breaking out more levels in future releases as the need arises. I would be very interested hear about your experience with the system once you roll it out, and we can talk more about further needs.
I am having trouble understanding the baseline space access rules. It seems like Looker has chosen a diminutive access model rather than additive one. What I mean is that all users are granted access to all spaces by default, and access must be removed. In other folder access management systems, access is default private to the folder owner and then added (a la Google Drive).
Why did you all decide to chose this method (if I have understood correctly)?
Is there any plan for granting access to groups of users or specific Roles (ie give the whole accounting team access to the “Accounting” Space? This would be in place of having to select specific users and manage user-level access. This can get quite cumbersome quickly when folks move from team to team or leave a company.
And as long as a user has the explore permission, they have access to anything within their model sets. So this design would only prevent them from editing a saved Look, correct?
Hi @rbixler -
You’re absolutely right - we designed a system that is open by default and provides the tools to lock down sensitive reports and make private Spaces as needed. We believe that data openness and a system that makes sharing reports and dashboards easy are foundations of a strong data culture within a company – that’s why Looker didn’t have access controls at all when it started.
We did build a Group system to accompany this change and make it easier to configure. On upgrade to Looker 3.54, one Group will be created for each Role that you already had in your system, and all users who had that Role will be assigned to that Group. You can redefine your Groups as needed to configure your system. Here’s an overview of our recommended way to step up a restricted system and more detail about our new Group system. To see and manage Groups, head to the new Group section in the Admin panel.
Finally, you are correct that access controls are a layer on TOP of our existing permissions system. A user who has the
explore permission and access to a given model but does not have Edit access to a Look cannot change that saved Look but can make new explorations from the data in that model. If they do not have View access to that Look, they will not even see that it exists.
Please let me know if you have any additional questions!
Experience so far has been quite good! Took me a bit of time to set everything up as wanted, but it seems to have gone successfully since I haven’t heard any complaints yet.
The only thing that I now keep forgetting is that whenever I create a new user I need to assign both a role and a group to that user. In our case the two are tied together, so would be good if assigning the role would suffice.
@chris.laumans Groups should have associated Roles, thus when you create a new user assigning them to a group should suffice.
oh ok, thanks! So just assigning the group would be enough. Good to know
@chris.laumans yep - the Groups that we automatically populated from your Roles already have a Role attached. Any new Group you make, you’ll need to assign the Roles. Then, once you assign a User to a Group, they will automatically get the Role(s) associated with that Group. You can double check any individual User by clicking Edit next to their name on the Users page in the Admin panel and going to their user profile. Their profile will call out the Roles assigned to them and the Groups they got them from.
Any ideas on managing access controls on spaces for embedded user? Will using ‘external_group_id’ be the way?
This would be managed by the group(s) the embed user belongs to. There’s the URL parameter
group_ids you can use to set this.