Atlantis: Enforce only certain people can plan/apply

[lkysow]

Via @psalaberria002, would like to be able to only allow certain people to run apply.

[psalaberria002]

Either certain people per repo, or those who have admin rights in the repo, or for some other repo those who have write access. It would be nice to have some flexibility here.

[msurovcak]

it would make a sense for our use-cases to not only have certain people to allow run apply, but as well limit their domain, eg. Alice can approve env/testing/, Bob can approve env/...

[natalysheinin]

A lot of this enforcement can be achieved through:

• using Github's codeowners feature: limit users/groups/emails on a per repo folder basis
• using Github's branch protection: protect this branch, require pull request reviews before merging, and require review from code owners.
• lastly, use atlantis' server config flag enabled: require-approval: true.

This way, you atlantis requires a review before allowing apply to run, and github forces the review to be from a specific person/group of people.

@msurovcak @psalaberria002 @lkysow

[lkysow]

@natalysheinin yes you're absolutely correct that the enforcement for who can approve can be done through CODEOWNERS (well at least if you're on GitHub).

The original ticket for who is allowed to apply can't be achieved through that though since once the pull request is approved anyone can apply. We should probably document how to achieve the approval enforcement though. Thanks for the reminder.

[lkysow]

I updated this to also expand to atlantis plan since some users are worried about plan being exploited.

[rayterrill]

Noting this is something we'd be interested in as well. We're also aware of things we can do on the Github side with CODEOWNERS and requiring approvals within Atlantis, but we'd love something simple like --apply-whitelist or something that would allow us to define a list of users who should be able to actually apply infrastructure with Atlantis. --plan-whitelist would also be very good although I'm personally less worried about that for our environment.

[natalysheinin]

It would be good if that whitelist was defined via CODEOWNERS as source of truth so that you don't need to manage two places at once!

[majormoses]

https://github.com/runatlantis/atlantis/issues/43 and https://github.com/runatlantis/atlantis/issues/308 for reference.

[mikeraimondi]

I'd just like to note that, in my testing, it's not possible to restrict who can apply using the require-approval server option in GitHub. This is due to the way approvals work in GitHub. Anyone with read access to a repository can add an approval. CODEOWNERS cannot limit who can review, it only causes automated review requests to be created.
There is a "Require review from Code Owners" option in GitHub's branch protection rules, but it doesn't help. "Require review" only means that the PR cannot be merged until it receives at least one approval from a code owner. And since the require-approval server option only checks that a PR has at least one approval in GitHub, not if the PR is mergeable, anyone with read access to the repo can add an approval and run apply.

[lkysow]

@mikeraimondi yes, Atlantis needs a mergeable apply_requirement. Then you can make those users required approvers which will make the PR not mergeable until they approve it. We can detect that.

[majormoses]

It's not currently doable but if you read through #43 if we make the serverside option for require-approval use the mergable state which depending on your branch protection setup should be (after the enhancement) be very doable.

[rikatz]

Hey :)

What if this was done as k8s CI robot, having a OWNERS and OWNERS_ALIASES per repository/folder specifying who can approve / run the commands?

https://github.com/kubernetes/test-infra/tree/master/prow/plugins/approve/approvers is an example :)

[jamengual]

This pull request :https://github.com/runatlantis/atlantis/pull/1206 Addressed this for Github but support for other VCS can be added.

Some of the solutions mention before are only available on Github Enterprise which we do not have and CODEOWNERS is pretty fragile, one bad char in the file and the whole file gets ignored, which is pretty bad.