Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lkysow opened this issue Mar 30, 2018 · 21 comments
Open

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

lkysow opened this issue Mar 30, 2018 · 21 comments
Labels
feature New functionality/enhancement help wanted Good feature for contributors provider/bitbucket provider/gitlab

Comments

@lkysow
Copy link
Member

lkysow commented Mar 30, 2018

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

@psalaberria002
Copy link
Contributor

psalaberria002 commented Mar 31, 2018

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
Copy link

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
Copy link

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
Copy link
Member Author

lkysow commented Jun 4, 2018

@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 lkysow changed the title Enforce only certain people can apply Enforce only certain people can plan/apply Jul 17, 2018
@lkysow
Copy link
Member Author

lkysow commented Jul 17, 2018

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

@rayterrill
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

majormoses commented Oct 21, 2018

#43 and #308 for reference.

@mikeraimondi
Copy link

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
Copy link
Member Author

lkysow commented Oct 26, 2018

@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
Copy link
Contributor

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.

@lkysow lkysow added the feature New functionality/enhancement label Apr 4, 2019
@rikatz
Copy link

rikatz commented Apr 22, 2020

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
Copy link
Contributor

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.

@chenrui333 chenrui333 added the help wanted Good feature for contributors label Dec 30, 2021
@jamengual
Copy link
Contributor

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

@nitrocode nitrocode changed the title Enforce only certain people can plan/apply Enforce only certain people can plan/apply for github, gitlab, bitbucket, etc Jan 17, 2023
@nitrocode nitrocode changed the title Enforce only certain people can plan/apply for github, gitlab, bitbucket, etc Enforce only certain people can plan/apply for gitlab, bitbucket, etc Jan 17, 2023
@thatsk
Copy link

thatsk commented Apr 27, 2023

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

@jamengual
Copy link
Contributor

jamengual commented Apr 27, 2023 via email

@thatsk
Copy link

thatsk commented Apr 27, 2023

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
Copy link

thatsk commented Apr 27, 2023

$ 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
Copy link
Contributor

jamengual commented Apr 27, 2023 via email

@dfsdevops
Copy link

dfsdevops commented May 3, 2023

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
Copy link
Contributor

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:

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 (

// 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement help wanted Good feature for contributors provider/bitbucket provider/gitlab
Projects
None yet
Development

No branches or pull requests