ATLANTIS_GH_TEAM_ALLOWLIST does not support nested team membership #6107
Description
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
- Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
- If you are interested in working on this issue or have submitted a pull request, please leave a comment.
- I'd be willing to implement this feature (contributing guide)
Describe the user story
Description: I am experiencing an issue where the ATLANTIS_GH_TEAM_ALLOWLIST variable only validates users who are direct members of the specified team. It does not seem to recognize users who belong to a child team (sub-team) of the parent team defined in the allowlist.
Current Behavior:
Parent Team A is added to ATLANTIS_GH_TEAM_ALLOWLIST.
Team B is a child of Team A.
User X is a member of Team B (and thus an indirect member of Team A).
Atlantis rejects User X, stating they are not in the allowlist.
Describe the solution you'd like
Atlantis should ideally respect GitHub's team hierarchy. If a parent team is allowlisted, members of any child teams should be authorized to run Atlantis commands, as they are logically part of the parent organization's structure.
Also, to make this variable work, the GitHub Personal Access Token (PAT) requires the read:org scope. This requirement is not explicitly highlighted in the current documentation, leading to "Permission Denied" errors that are difficult to debug.
Describe the drawbacks of your solution
Describe alternatives you've considered
Using child team as perm