Enforce only certain people can plan/apply for gitlab, bitbucket, etc

[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]

#43 and #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 :#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.

[jamengual]

The teams allowlist command has been added to github but it has not been added to gitlab or bitbucket so help is still wanted

[thatsk]

is there way we can do in bitbucket or still this issue

[jamengual]

not currently. this was added to github only. PRs are welcome .

…

On Thu, Apr 27, 2023, 1:03 a.m. Thatsk ***@***.***> wrote: is there way we can do in bitbucket or still this issue — Reply to this email directly, view it on GitHub <#103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3ERHYDWA3RPZI35X52SDXDIR3XANCNFSM4EYIQCWQ> . You are receiving this because you commented.Message ID: ***@***.***>

[thatsk]

can we implement a normal script like this?
https://github.com/nitrocode/atlantis-terraform-module/blob/d6d2bf74dff3c30b52232f1edd57dca0251be750/repos.yaml#L102-L105
Bitbucket users has uniuqe account_id so if we can pass in users file with approved authenticated users then its possible?

[thatsk]

$ curl https://api.bitbucket.org/2.0/repositories/foo/bar/forks \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "my_fork",
    "owner": {
      "account_id": "557058:c0b72ad0-1cb5-4018-9cdc-0cde8492c443"
    }
}'

[jamengual]

yes you can do that if you already have a way to extract that information.

…

On Thu, Apr 27, 2023 at 8:01 AM Thatsk ***@***.***> wrote: -H 'Content-Type: application/json' \ -d '{ "name": "my_fork", "owner": { "account_id": "557058:c0b72ad0-1cb5-4018-9cdc-0cde8492c443" } }'``` — Reply to this email directly, view it on GitHub <#103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3ERBGT4H5TDCVNOMHGPLXDKC3LANCNFSM4EYIQCWQ> . You are receiving this because you commented.Message ID: ***@***.***>

[dfsdevops]

The reason why mergeable isn't a sufficient solution to this issue IMO is that if you require atlantis apply before merging you have a circular dependency. It is desirable to require atlantis apply before merging so that you guarantee the the current code in main has been applied.

[lukemassa]

I use gitlab, and we've implemented this via mergeable + Gitlab's Merge Request Approval Rules. In gitlab, typically anyone can "click" approve, but approval rules are such that an MR is not "actually" approved until some number/specific users/etc. Gitlab's implementation of PullsIsMergeable prevents apply until all rules are satisfied:

atlantis/server/events/vcs/gitlab_client.go

Line 323 in 90f6324

mr.ApprovalsBeforeMerge <= 0 &&

.

I recently proposed an update #3830 that, among other things, changes the docs to explicitly say that anything more complicated than "at least one user has approved" should be implemented via mergeable.

@dfsdevops I haven't thought about a desire to have atlantis apply happen before merge, how is that implemented?

I wonder if we could on a per VCS basis "ignore" that as part of the mergeable check. For example, on gitlab we currently ignore a "failing" CI job if it is atlantis itself (

atlantis/server/events/vcs/gitlab_client.go

Line 305 in 90f6324

// Ignore any commit statuses with 'atlantis/apply' as prefix

), depending on how it's implemented I wonder if the same might help prevent the circular dependency issue.