Atlantis: Support for atlantis.yaml only from a specific branch

Created on 18 Oct 2018  路  4Comments  路  Source: runatlantis/atlantis

Currently if we use an atlantis.yaml anyone who makes a PR can inject adhoc commands. It would be preferable if we could restrict the atlantis.yaml to say the master branch. Where a user could PR an atlantis.yaml, but it would have to be approved and merged before it would take effect.

This would limit the adhoc commands to needing to be approved by someone and merged instead of just anyone who can created a PR.

feature

Most helpful comment

@lkysow I don't think server-side config solves this problem. We have a use case where we have multiple projects and each one may have different workspaces and/or workflows. Each project is owned by a different team and they should have the flexibility to customize their workflows, apply requirements or workspaces used. Using a server-side config would limit their ability to do this and involve another team to perform their updates.

Using repo side config grants them this flexibility. However, it allows a bad actor to change the config in their feature branch and bypass any protections in place. By restricting the repo side config to the master branch this would ensure that a PR has to be approved and merged before that configuration takes effect.

Granted, only trusted developers should have access to the repo but if a disgruntled employee decides to rage quit on the last day they could cause harm.

All 4 comments

Sounds a little bit related to this discussion: https://github.com/runatlantis/atlantis/issues/43

It's similar, but does not accomplish the same thing. In my case I never want atlantis to run using a atlantis.yaml from the commited code.

I only want the atlantis.yaml to run from master even if someone changes it on their branch.

Server-side config should solve this. You can specify your commands on the server side and not allow repos to do anything.

@lkysow I don't think server-side config solves this problem. We have a use case where we have multiple projects and each one may have different workspaces and/or workflows. Each project is owned by a different team and they should have the flexibility to customize their workflows, apply requirements or workspaces used. Using a server-side config would limit their ability to do this and involve another team to perform their updates.

Using repo side config grants them this flexibility. However, it allows a bad actor to change the config in their feature branch and bypass any protections in place. By restricting the repo side config to the master branch this would ensure that a PR has to be approved and merged before that configuration takes effect.

Granted, only trusted developers should have access to the repo but if a disgruntled employee decides to rage quit on the last day they could cause harm.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

alistar79 picture alistar79  路  5Comments

cheethoe picture cheethoe  路  4Comments

teosoft123 picture teosoft123  路  5Comments

richstokes picture richstokes  路  3Comments

ldormoy picture ldormoy  路  6Comments