As a company, we have our own access control (integrated with LDAP) to assign permissions. Gitlab allows us to sync these permissions to Gitlab roles using LDAP synchronizations.
There currently seems no secure way to prevent overriding these synced permissions, namely masters and owners can still add (or override) members.
The lock membership feature is not useful because it can be turned off.
This makes our business' access control less authoritative than we need it to, to stay compliant (for example, with SOX).
We'd like it to be possible to make the LDAP synchronizations fully authoritative for group and project membership. The only way to override membership synced by LDAP synchronizations should be by means of administrator intervention.
Proposal
An option in Gitlab that will lock down membership to a group and its projects to LDAP synchronizations only.
Add this option to the "Visibility and access controls" section of the "General" area of the admin settings panel:
Rename "LDAP group settings" to "LDAP settings"
Add "Lock memberships to LDAP synchronizations" as a toggle-able checkbox. This should default to false.
Like the existing Allow group owners to manage LDAP-related group settings, both LDAP options should only be displayed if LDAP is configured.
When this lock is enabled, only an Administrator may be able to: 1) Add/Remove members 2) Change the access level of existing members.
Only an administrator may be able to enable/disable the lock.
When this lock is enabled or disabled, log an audit event.
When this lock is enabled, we should remove all existing users added to projects/groups outside of LDAP. We should inform the admin enabling the lock that this will take place.
For groups without LDAP group sync enabled:
Group Owners should not be able to add members manually to these groups. Instead, they should see an error.
Instance administrators should be able to add members manually with the LDAP lock enabled.
Thanks for the feedback @tdevelioglu and @LongLiveCHIEF, this is a nice improvement. It should be relatively straightforward since we've got most of the pieces of the puzzle already.
We don't have capacity in the next release, but I have added this to the %"Next 2-3 months" milestone so that it will be addressed soon.
It may be a bug, but I'm currently experiencing this now. I recently added LDAP synchronisation to an existing group, and it removed all of the non-LDAP members, and I no longer even have the ability to add new group members. I have to add them explicitly to each project.
Thanks for the patience here. Let me restate the issue and echo the solution - if LDAP group sync is active, disallow overriding these permission settings from the sync and disallow adding or removing members. This would be an admin-level setting.
The milestone feels fairly accurate, as of now. We'll see if we can't get to this within a few months. @teemo, let me know if you'd like to discuss.
only an Administrator may be able to: 1) Add/Remove members 2) Change the access level of existing members.
means. Is that the overall Gitlab installation Administrator or the project owner?
My use case is that we still want the project owners to retain the choice and ability to add new LDAP groups but not individual members. We have tens of thousands of repos, so turning this on/off on a per-repo basis is not feasible. We need to turn it on/off on a GitLab server-wide basis.
As part of this discussion one should consider local users that are part of a group. If one needs to disable per-project access to "invited" users (ie locally specified users instead of users who receive access via an LDAP-synced group) one also needs to consider the same for groups.
There is another issue raised that seems to be in direct opposition to this one. https://gitlab.com/gitlab-org/gitlab-ee/issues/1793
They are requesting the LDAP controls be overridden by adding members even when LDAP groups are being utilized. If that occurs the audit-ability will be severally weakened.I know my organization needs to have the access controlled solely by LDAP groups so that individual access cannot be granted even at the project level. There are legal and security compliance for us to maintain. If people want the ability to override LDAP only access then please have it as a setting administrators can manage.
This case seems to be covered by the global setting we have - 'Allow group owners to manage LDAP-related settings'. If unchecked, only global admins can manage LDAP group links, etc.
There is another setting at the group level: 'Prevent adding new members to project membership within this group'. But I assume this is able to be controlled by a Group Owner so it probably still has some concern.
At one point in the past we discussed that perhaps the solution in some of these cases is that the org should decide to restrict group owners to global administrators. But maybe we can also consider that when this 'Allow group owners to manage LDAP-related settings' is unchecked that any group setting regarding members if not changeable by group owners.
Would appreciate any input on how I'm thinking about this:
The problem: we want to create an environment where an instance can use LDAP as their single source of truth for authorization. We also want to allow for some flexibility, however. Some instances may need to allow outside vendors or contractors access into their instance without adding them to LDAP.
The proposal:
This issue would add an admin-panel level setting that can only be toggled by GitLab administrators. When checked, only admins would be able to manually add users to groups OR projects outside of the LDAP sync.
We should also add this as an audit event.
To allow for some flexibility, we need a setting to optionally extend manual member management to group Owners. I agree that it makes sense to simply add this behavior to "allow group Owners to manage LDAP-related settings" as @dblessing described.
What happens when this is unchecked? Members of groups (and their subgroups/projects) are not manually editable by Owners.
What happens when this is checked? A configuration option is exposed in group LDAP settings that reads "Lock membership of this group to LDAP". This should default to true.
When the LDAP lock is disabled, I suggest we notify the user making the change that they'll be able to add members to the group and subgroups/projects. We should leave the group's membership unchanged.
When the LDAP lock is re-enabled, I suggest we err on the side of caution and remove all members who have been manually added. We should warn the user making the settings change that some users who are outside of LDAP may lose access.
With this approach, someone like @stephen.m.carlson can just turn on the admin-level setting to lock memberships to LDAP. If "allow group owners to manage LDAP-related settings" is unchecked, managing this stays at the admin level and can't be worked around.
If you're an organization that uses LDAP but is concerned about the extra burden on GitLab administrators, you can consider enabling "allow group owners to manage LDAP-related settings" and promote other users to Owner level for select groups.
One thing we've run into on our 11.2.3 instance is that, currently, LDAP-managed groups can't delegate/invite permissions to other GitLab groups, even if that group is also LDAP-synced. We'd like to be able to set up a membership-only (no projects) LDAP group, and invite it to have Maintainer privileges on an individual projects basis within an LDAP-synced GitLab group.
I know these member-only groups/teams are coming soon without this workaround, but can that be considered for the rollout here? We want to maintain LDAP-controlled access to specific projects, but the additional flexibility of adding project-level permissions granting/sharing to other LDAP-synced groups would be ideal.
Additionally, once a group is synced to LDAP, it technically no longer needs an Owner (since group membership is no longer managed within GitLab). And our Security Engineering team doesn't actually want to let any of the group users to be Owners, as they could then remove the LDAP synchronization.
As the GitLab admin for my organization I'm now the Owner of a group I created and synced to LDAP, but this means I'm getting emails for all the projects & MRs in that group. And I can't remove myself as Owner because GitLab doesn't seem to allow the only Owner to leave. Is there a way to remove my ownership? As a temporary workaround, would it be possible to unsubscribe from all member email notifications for the group?
And our Security Engineering team doesn't actually want to let any of the group users to be Owners, as they could then remove the LDAP synchronization.
@jeremy that works for the notifications. I'd prefer not to actually be a member of a group just because I administratively created it. But I might possibly end up being able to leave the group after I can set up an Owner LDAP group and disallow them from breaking the LDAP sync connection.
a group of projects has an LDAP group granted Developer privileges
a workaround "team" group of people is created, also with LDAP sync (all members are a subset of the Developers group from above)
a project is created in the group from 1)
the project from 3) is shared to the team group in 2), in an attempt to let that team be Maintainers
the team group doesn't actually get maintainer rights on the project. I know the "share with group says "Max access level," but it's not at all clear how it should work or why (and it definitely didn't work how I expected).
Note that I don't want the team members to be maintainers of the whole group namespace, just on projects they own/maintain within the group. And it's all still LDAP-controlled, though not all in the same namespace.
@jeremy I think the issue description makes sense. I have a few more questions on how this will work:
In EE, we have the ability to override access levels for users from LDAP sync. With the lock option, do we remove these overrides when this checkbox is active? I don't think we have a good way to "ignore" overrides in case the admin changes his/her mind, so we will likely need to remove these entries from the database (e.g. all rows in the members table with the override attribute set).
In general, this LDAP lock button could have a lot of side effects (e.g. lots of memberships get revoked, e-mails generated, project auth refreshes, etc.). Do we need to be very careful about warning admins that if they activate it, all custom members will be lost?
As the GitLab admin for my organization I'm now the Owner of a group I created and synced to LDAP, but this means I'm getting emails for all the projects & MRs in that group. And I can't remove myself as Owner because GitLab doesn't seem to allow the only Owner to leave. Is there a way to remove my ownership?
I don't think there's currently a way to remove ownership at the moment, but perhaps we should allow that if LDAP lock is used? That is a separate issue.
As a temporary workaround, would it be possible to unsubscribe from all member email notifications for the group?
If you go to the Notification settings in the group, can you select Disabled?
In EE, we have the ability to override access levels for users from LDAP sync. With the lock option, do we remove these overrides when this checkbox is active? I don't think we have a good way to "ignore" overrides in case the admin changes his/her mind, so we will likely need to remove these entries from the database (e.g. all rows in the members table with the override attribute set).
Good point. Ignoring overrides when this option is checked definitely feels like complexity that's not necessary in this iteration. I think we'll have to consider the UX when this option is checked, but I vote to inform the admin that any overridden access levels will be discarded as part of the LDAP lock.
In general, this LDAP lock button could have a lot of side effects (e.g. lots of memberships get revoked, e-mails generated, project auth refreshes, etc.). Do we need to be very careful about warning admins that if they activate it, all custom members will be lost?
Yes, absolutely. In my mind, I'm thinking of a visual treatment similar to blocking a user:
@matejlatin, would you be able to suggest an approach? Even a rough wireframe would be helpful. I'm not sure if we have any similar patterns that we use in admin settings.
In general, this LDAP lock button could have a lot of side effects (e.g. lots of memberships get revoked, e-mails generated, project auth refreshes, etc.). Do we need to be very careful about warning admins that if they activate it, all custom members will be lost?
Yes, absolutely. In my mind, I'm thinking of a visual treatment similar to blocking a user:
Yes, definitely. Based on the comments it seems we do need to warn the user appropriately.
Is it safe to say this lock to LDAP setting will not affect admins being able to login to an instance to change LDAP settings if their LDAP server moves or is offline?
This doesn't affect authentication itself. It's only dealing with group sync and locking group membership. If LDAP is offline and the admin wants to be able to manually manage group membership for a short time, they will have to turn off this lock.
I wrote there: "The solution needs to give customers (@xyzzy@pharlan@vehernandez) a setting that gives them confidence that LDAP is the single source of truth for their instance. If they want to achieve this if we allow adding of members to groups without LDAP group sync, I think an administrator would have to:
Enable LDAP sync lock,
Disable "allow group Owners to manage LDAP-related settings",
Enable LDAP group sync for all groups and subgroups on the instance.
It's the last one that I'd like to get some clarification on. I can't remember if LDAP group settings get inherited to subgroups; in other words, if I have a complex series of groups and subgroups, do I need to enable LDAP group sync for all of them? If not, then the admin's job is more straightforward. If so, it'll be a lot of administrative overhead to make sure there aren't any compliance holes which may defeat the purpose."
I'd like to validate (perhaps with folks like @brad.beyenhof) that we should err on the side of caution here and disallow the manual adding of members to groups that don't have LDAP group sync enabled:
Group Owners should not be able to add members manually to these groups. Instead, they should see an error.
Instance administrators should be able to add members manually with the LDAP lock enabled.
I struggle a bit to find expected access levels with this option enabled. We have several actions related to groups and projects and LDAP sync.
@jeremy can you review and comment on every statement below:
When app-wide lock is disabled everything should stay as it is now.
When app-wide lock is enabled following should be true:
Management of members and their permissions of any personal project (not in a group) as well as "share with a group" functionality should stay as it
LDAP sync options for any group should be visible to admins only.
Members and their permissions of any group can be added, removed, updated by LDAP sync and admins only.
Members and their permissions of any group project can be added, removed, updated by LDAP sync and admins only.
"Invite a group" functionality is allowed to admins only for group memberships and group project memberships.
All statements above should be true even if a group has no LDAP configured or wasn't synced yet.
@jeremy another question related to automatic clean up when you enable the lock:
Admin can manually add\remove members even with the lock enabled
Automatic cleanup removes all the customizations (overrides, extra members etc) on lock enabling.
If an admin removes the lock occasionally there is no way to enable the lock back without an automatic cleanup. So admins are forced to stay with the lock disabled or sacrifice all existing customizations.
After a conversation with @pshutsin on Slack, an update here for the issue:
The current MR adds a global LDAP membership lock and has a good chance of making it into %12.0 if merged by end of day tomorrow.
The functionality of this improvement is described here.
This MR doesn't include 3 planned additions, which we'll pursue in separate issues:
Automatic clean-up of manual overrides; in the current MR, these manual overrides are preserved instead of being destroyed and using LDAP permissions as the single source of truth;
Toggling this setting on/off doesn't trigger an audit event;