Use of GitLab groups as first class concept for authorization.
Problem to solve
A customer enquired (internal links) about how to assign groups to protected environments.
As part of my analysis, I suggested using GitLab groups exclusively to represent groups of people, and specifically to act as a proxy for an LDAP group. This approach came as a surprise to a number of folks working with GitLab for this customer.
The documentation doesn't clearly refer to a pattern of using groups just for user management. For example, on the groups page
- Add users to a group refers to group structures that also contain projects
- Sharing groups and projects with each other
- Group sync from LDAP
Intended users
User experience goal
It's the undocumented piece in the puzzle for managing authorization on enterprise scale.
Organizations should, early on, think about creating a root group and a structure for containing authorization groups.
Proposal
Should be possible to do this with documentation.
Further details
A very common pattern is for organizations to handle authorization via directory groups, eg: Active Directory / LDAP. And then they will want to use those groups inside GitLab.
Teams or groups such as:
- People who write the code.
- People who review the code and has access to merge it.
- A group of internal users who sign off changes in UAT.
- A team which deploys to production.
These will be represented by groups in LDAP.
Organisations might also be a role-based access approach, ensuring that when people change roles, employees gain and lose access along with the change in role.
Once there's a group in GitLab with a number of members in it (populated manually, or synced from LDAP) it can then be used inside GitLab for authorization; features such as:
- Protected branches
- Protected environments
- Protected tags
- Merge request approvals.
For protected branches, environments, tags:
- The only way to use groups is to share the project with the group, perhaps just with guest access. Then, and only then, does a project appear in the selection list.
- LDAP groups don't appear in the list. They have to first be proxied in GitLab as a GitLab group.
Screenshots: how to make groups appear in the authorization list
- group invited to project
- Settings -> CI/CD -> Protected environments
- Settings -> Repository -> Protected tags
- Settings -> Repository -> Protected branches
For merge request approvals, any group in GitLab can be selected, but the same constraint on LDAP applies.
Screenshot: access groups visible for MR approval rules
Given that LDAP groups cannot be selected directly, it would be most scalable if customers had a section of their GitLab group hierarchy just for syncing in LDAP groups for use with these sorts of features. (see the screenshot for MR approval rules)
If they have a separate group for doing access requests (segregation of duties) then the access-groups hierarchy can be locked down to that group only.