Create "No Access" Role
The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Problem to solve
In Gitlab.com, we use top-level groups as the construct that defines an organization's workspace. If an organization is using SSO, users are automatically added to the top-level group as Guest, which for some organizations is too permissive. In a self-managed instance, administrators can add users to an instance and selectively add them to groups/projects as needed. We need to simulate that experience for Gitlab.com customers.
Intended users
User experience goal
Administrators can add members to the parent group for SSO purposes but they don't automatically have access to projects/groups underneath. This is one of the top reasons why customers want to disable inheritance (#33534 (closed)). If we had this feature we could essentially ask administrators to add users to the levels they need access to instead of marking what needs to be excluded from the hierarchy. So a similar result but a different way of tackling the need.
Proposal
Create a role that gives no access to top-level resources. The experience should be similar to not existing in the top-level group.
- The "unassigned" role should only be assignable to users in the top-level group via the UI or API.
- A user with the "no access" role should not be able to list subgroups/projects unless they have been explicitly added to them.
- If a user with the "unassigned" role is explicitly added to a group further down in the hierarchy, our existing inheritance model will apply to any subgroups or projects underneath.
- A user with the "unassigned" role should not have access to any of the top-level group resources.
- If a "unassigned" role user hasn't been added to any other group/project, all they will see in their groups is the top-level group. Trying to access it will give them a limited view of the group. In the section where the group hierarchy is normally shown they will see a message "You don't have access to any resources in this group."
- Users with the "unassigned" role are shown in the members list if they are direct members. Users with the "unassigned" role are not shown in the members list if they are inherited members.
- This role should be available as an option in the
Default membership rolein SAML/SSO configuration. - This role should be available in gitlab.com and self managed. Silver/Premium and above.
Further details
A huge challenge with disabling group inheritance has been the sensitivity of the underlying code. It is proving very hard to change. As pointed out in @mksionek's MR, we're now considering a working group and doing more investigation on all the potential effects.
-
MyCompany (top-level group)
- SecretGroup (subgroup)
- General (subgroup)
Since SAML is currently configured at the top-level group, users will SSO in. At a minimum, they have Guest access to MyCompany group, so they have Guest access to all subgroups. This includes SecretGroup, so it's not possible to keep the projects in SecretGroup confidential.
Instead of allowing members to be in MyCompany as Guests at minimum, introduce a No Role membership. New members who are added to MyCompany via SAML or otherwise get added as No Roles to MyCompany.
Being a No Role means that you can do almost nothing in the group. While inheritance is technically still in place since No Role is being inherited into SecretGroup and General, it doesn't matter since you can't do or see anything with No Role.
Therefore, I need to add/update my member's specific roles in SecretGroup and General. For a new member, I can just add them to General as a Guest ... Owner to give them access where they can start contributing. Their No Role access in SecretGroup means that subgroup remains a secret.