In 13.4, the ability was added to allow Members with only the “Reporter” role to have access to a Protected Environment.
Per the documentation (https://docs.gitlab.com/ee/ci/environments/protected_environments.html#environment-access-by-group-membership), only Reporters that are a member of a Group can actually be added to a Protected Environment.
However, the following scenario also works:
- Add a user to the Project (or parent Group) as a “Developer”
- Grant that user access to the Protected Environment
- Change that user’s role to “Reporter”
The user retains access to the protected environment. If the user is a “Reporter” before being added the the Protected environment, as documented it isn’t possible.
So while the above scenario on the surface seems to be a bug/loophole, this would actually be the desired behavior over the current process of having to have a separate group created first. The problem with a separate group is the potential for needing hundreds of different groups created if you have hundreds of applications with different users that need to have access to deploy, and you can’t stuff them all in a single group. In addition, the owners of those groups must be someone within that group - you can’t delegate the maintenance of those groups to anyone that might not be authorized to also be a deployer because they would then incorrectly have access to Protected Environment(s) to which they shouldn’t have access.