Default access rights for new spaces

[Dimitri_Masin]

Hi all,
I have the following problem:

I’ve shared the “shared” space with all groups in the company. If I don’t do this, then I can’t share the spaces within the “shared” folder with groups that don’t have access to the root (i.e. the “shared” space).

This leads to a weird default state where all newly created spaces are by default shared with everyone (if people forget to exclude groups)

I would like to have one Looker group (e.g. Investors) that has access only to one space unless it’s explicitly added to a different space by somebody. I can set it up easily. But every time somebody creates a new space, it ends up being shared with all group.

Maybe I’m just not doing it right 🙂 Would appreciate any advice.

Best,
Dimitri

[will_adams]

Hey Dimitri,

Sounds like you’re on the right track, a space by default inherits the access permissions of it’s parent, so you will need at least view access on the shared space for the Investors group. This means that new spaces will be viewable by Investors, and that permission would have to be removed manually.

I’d recommend using a notification (https://docs.looker.com/admin-options/tutorials/notify-users) to inform your analysts that they’ll need to be mindful of that, and consider an API job to scan and fix spaces that don’t conform to that policy. Good article on API space management here: Manage Space Access with the API

Also, this doc on space in general could be useful here: https://docs.looker.com/sharing-and-publishing/organizing-spaces

[Dimitri_Masin]

Thanks @will_adams. It seems to me like a super standard use case where one group should have access to one folder only and I can imagine it for every Looker customer. How come we need to write a scripts which periodically scans the permissions via API etc.

Is it something on the road map to fix or is it generally not recognised as important enough feature?

[philip_martinel]

hey @Dimitri_Masin,

Jumpin in here. Fundamentally, users cannot see any child spaces in the parent shared space (which is basically a container for all spaces other than personal spaces) unless they have view access to the shared space. This cannot currently be changed, as it’s the intended behavior. If you want to restrict groups to certain spaces, then the recommended setup is to grant all users/groups view access to the shared space, but grant access (view or otherwise) to child spaces on a space by space basis.

The API can just be a more efficient/automated way of doing this, but it’s not necessary.

Thanks,
Philip

[svickers]

We’ve had issues with this as well, it seems like a funny setup. While the API and scheduled jobs will work, it is a pretty janky setup that has to be maintained and monitored as well…especially if you are relying on it for access restrictions.

I would recommend accepting that users will see dashboards that they can’t use. Make sure your model and data permissions are dialed in so if they get to a dashboard, they wont see anything in it.

[Dimitri_Masin]

svickers:

I would recommend accepting that users will see dashboards that they can’t use. Make sure your model and data permissions are dialed in so if they get to a dashboard, they wont see anything in it.

Thanks for the confirmation @svickers. We have overall only one data model so we will unfortunately need to accept that some of the data will leak to users that should not access it. That’s a shame.

[bernard_kavanag]

Dimitri_Masin:

unfortunately need to accept that some of the data will leak to users that should not access it. That’s a shame.

Hi Dimitri,

It sounds like you can use the option to Mask Sensitive Fields for Certain Users.

This involves setting user attributes in a CASE WHEN statement. If the attribute evaluates to true then users can see the data. If it evaluates to false users will see the string declaration in the THEN clause.