./atlantis testdriveand it will create a demo repo you can use to talk to atlantis
applycommands on the server Atlantis is hosted on. Just like when you run Terraform locally, Atlantis needs credentials for your specific provider.
AWS_ACCESS_KEY, where Atlantis is running.
~/.aws/credentials, where Atlantis is running.
atlantisare the default ones).
atlantis servercan be specified via command line flags, environment variables, a config file or a mix of the three.
/atlantis.ymlfile. This file can be used to specify how atlantis should treat the repo. However, by default some keys cannot be specified here without some flags allowing it.
approvedby somebody else (even if that isn't set in the branch protection) and/or be **
mergeable** (branch protections passed) before running apply. From a security point of view, to set both options a recommended.
allowed_overridesis True, these setting can be overwritten on each project by the
atlantis plan** (or maybe it's automatically executed) you will be able to RCE inside the Atlantis server.
atlantis applyyou will be able to RCE inside the Atlantis server.
atlantis applyif the PR is mergeable (which means that the branch protection need to be bypassed).
atlantis applyterraform is being run under-needs, you can pass commands to terraform from atlantis commenting something like:
atlantis.yamlfile. Atlantis uses the
atlantis.yamlfile from the pull request branch, not of
master. This possibility was mentioned in a previous section:
atlantis plan/applycomments on your valid pull requests, it will cause terraform to run when you don't want it to.
atlantis plan/applyand gain RCE.
--repo-allowlistthen they could only fake requests pertaining to those repos so the most damage they could do would be to plan/apply on your own repos.
/home/atlantis/.git-credentialsContains vcs access credentials
/atlantis-data/atlantis.dbContains vcs access credentials with more info
<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstateTerraform stated file
/proc/[2-20]/cmdlineCmd line of
atlantis server(may contain sensitive data)
--allow-fork-prs(defaults to false) because anyone can open up a pull request from their fork to your repo.
--repo-allowlistflag. For example:
--repo-allowlist=*. Useful for when you're in a protected network but dangerous without also setting a webhook secret.
atlantis server --helpfor more details.
terraform applyapprovals are not enough. It is possible to run malicious code in a
terraform planusing the
externaldata source or by specifying a malicious provider. This code could then exfiltrate your credentials.
planstep to validate against the use of disallowed providers or data sources or PRs from not allowed users. You could also add in extra validation at this point, e.g. requiring a "thumbs-up" on the PR before allowing the
planto continue. Conftest could be of use here.
$ATLANTIS_GITLAB_WEBHOOK_SECRETenvironment variables. Even with the
--repo-allowlistflag set, without a webhook secret, attackers could make requests to Atlantis posing as a repository that is allowlisted. Webhook secrets ensure that the webhook requests are actually coming from your VCS provider (GitHub or GitLab).
--web-basic-auth=trueand setup a username and a password using