Inherited group membership and a contractor’s 404
Your company has a top-level group acme with subgroups platform and data. The data subgroup contains project etl-pipeline. A contractor, Priya, needs to read code and comment on issues in etl-pipeline only. An administrator adds her as Guest to acme because Guest is read-only. Priya cannot see the repository in her dashboard, and a direct link to a source file returns 404. Separately, an engineer added as Developer to platform can push to data/etl-pipeline even though he is not on that team. The security team asks why a different contractor who is a Reporter on etl-pipeline can open a confidential issue titled Vendor credentials rotation. No project visibility has changed; it is Private. The company has 240 users across 14 subgroups and wants least privilege without a membership request for every project. The admin insists group-level membership is always simpler and safer.
1. Why does Priya get a 404 on a source file, and what is the minimum correct membership for her? Explain the inheritance path.
Read the worked answer
GitLab group membership is inherited downward. Adding Priya as Guest to acme gives her Guest on every project under acme, including data/etl-pipeline. Guest can view the project and participate in issues, but Guest cannot read repository contents, so a direct link to a source file resolves as 404 rather than 403. The minimum role that can read code and comment on issues is Reporter, but it should be granted at the project level, not at acme. Recommended change: remove the acme Guest membership and add Priya as Reporter to data/etl-pipeline only. If she later needs only issue participation and no code, use Guest at the project level. This keeps least privilege and avoids giving her access to the other 13 subgroups. A 404 on a file is a permission symptom, not proof the project does not exist.
2. The engineer in `platform` can push to `data/etl-pipeline`. Is that expected inheritance? What should the admin check and change?
Read the worked answer
Sibling subgroups do not inherit from each other: Developer in platform should not, by itself, grant anything in data. Expected causes are: he also has a membership higher up, such as Developer at acme; data/etl-pipeline has invited the platform group as a group member; he is a Maintainer/Owner through another group; or branch protection is weak and a Developer can push to an unprotected branch. Check the project Members page and filter by Inherited to see the source. Fix by removing the broad acme or data membership and granting project-level Developer only where needed; remove any group invite from platform to data; protect main so Developers cannot push directly. For 240 users across 14 subgroups, use project-level membership for cross-team work and reserve top-level membership for a small admin group. Audit inherited memberships quarterly.
3. Why can the Reporter contractor see the confidential issue, and what is the smallest safe change?
Read the worked answer
Confidential issues are not a separate permission object; they are visible to project members with Reporter or higher. The contractor is Reporter on etl-pipeline, so the confidential issue is within their role. If that contractor must not see security-sensitive issues, the smallest change is to lower them to Guest on that project, because Guest cannot view confidential issues. That also removes code read access, so confirm whether they still need code. If they need code, Reporter is the minimum role that includes it, and it will also include confidential issues; in that case isolate sensitive issues in a separate private project with a smaller membership, or use a separate security project and link only the non-sensitive work. Do not rely on Internal visibility for secrets: Internal exposes the project to authenticated users, and role inheritance still applies.