Restrict instance membership changes to a single user
Problem
In #4354 (closed), we added a capability to lock membership changes in GitLab to LDAP sync (and administrators). This is useful for organizations who choose to use LDAP as the single source of truth, but an instance may not always use an LDAP connection with their authentication solution.
An IAM system from a vendor like Sailpoint or Saviynt may use a custom connector that doesn't rely on LDAP configuration in GitLab, but instead make membership changes through a service user using GitLab's API (e.g. Members API).
Proposal
- Extend the membership lock introduced in #4354 (closed) to either lock to LDAP sync or a designated user.
- This lock should cover both project and group membership.
- When enabled, the designated user should be the only user who is able to make membership changes on the instance (aside from administrators).
- Project/group Owners/Maintainers attempting to add/remove members from projects/groups should receive an error and guidance to contact their GitLab administrator if they'd like to make membership changes.
See https://docs.gitlab.com/ee/administration/auth/ldap-ee.html#global-group-memberships-lock for documentation on the LDAP sync lock.
Availability & Testing
What risks does this change pose to our availability?
This feature is low risk to the availability of GitLab.com
What additional test coverage or changes to tests will be needed?
- The setting should only allow selecting a user with Admin role.
- When enabled, only the designated Admin user should be able to:
- Create a new user in the instance or edit an existing user via the /admin/users UI
- Invite a user or a group to a project via the UI
- Invite a user or a group to a group via the UI
- Add or modify users via the user's API
- Add or edit members via the [Group and project members API](https://docs.gitlab.com/ee/api/members.html#group- and-project-members-api)
- Non-designated admins should not be able to perform the above actions.
- All users should still be allowed to create new projects, groups, sub-groups and sub-projects and in such cases, any inherited members would still be added to the created projects, groups, sub-groups or sub-projects even if the creator is not a designated Admin.
- Any existing project and group memberships should be retained when the feature is turned on.
Appropriate coverage for above cases should be added at unit and feature levels. No end-to-end test would be needed.