#atlantis - May 2020

Hi guys - I'm wondering if anyone has advice for setting up an Atlantis to manage multiple environments (dev/stg/prd) within the same AWS account (cannot split them unfortunately): Unclear to me right now how to manage permissions for users so the environments are isolated (based on AWS)

@Padarn I was deploying and enabling for the first time Atlantis for our team and and when I was testing I realize of a somewhat huge problem!!!, my repos are like terraform-team-rds and we define the environments by .tfvars files and then we call -var-file and that is how we can initialize the environments so if the sam repo for all environments so if I deploy another atlantis in the prod account then the repo is going to have two webhooks so it will receive from the same events plan or apply` commands and then both atlantis server will populate the PR, one with a successful run and the other one with a incomplete run, which is far from ideal since the PR will get polluted

So there is I think two ways to do this : one is to maybe set a webhook that only send events on releases for prod and then do apply but I have no idea if that will work and the other way it costs $6 bucks a month and is to use WAF to parse the POST payload of the webhook and look form something and block it if it does not contain that magic word, that in my case I set it up to be environment: staging

after doing this the staging atlantis only received the events that need to process

not the best solution but it was very easy to setup, if atlantis could deal with this will be ideal

having to move to having modules per environment will not be fun

and the amount of repos will be crazy

This is a good point (I hadn't worked on this in the weekend). I am using gitlab, and there is one possible simple solution: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19513. It Is possible to filter webhooks based on the branch

but, it seems like (from what I can see) this only filters for "push events" with is not ideal

push events and not comments

mmmm

it looks a bit like using this: https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#enabling-atlantis-yaml

you could define a workflow only for staging for your staging intance

but this setup is getting pretty messy

@Erik Osterman (Cloud Posse) is this still in the cloudposse fork https://github.com/runatlantis/atlantis/pull/310

If a terraform module (module UP) is updated, is there a way for atlantis or something else to rerun a terraform plan for a module (module DOWN) that depends on UP ?

need some help, mostly cloudposse guys since I use their fork : I’m defining this as my atlantis.yaml

version: 2
projects:
- name: staging-us-east-2
  dir: .
  workflow: staging-us-east-2
  terraform_version: v0.12.24
  autoplan:
    when_modified: 
      - "*.tf"
    enabled: false

- name: production-us-east-2
  dir: .
  workflow: production-us-east-2
  terraform_version: v0.12.24
  autoplan:
    when_modified: 
      - "prod.txt"
    enabled: false

I created a PR that does not have the "prod.txt" file but when I run atlantis plan -p production-us-east-2 atlantis goes and runs the the plan

I’m trying to avoid that by using the prod.txt file as a feature enable flag kind off

is that possible ?

does the file have to exist in order for this to work ?

this is just for autoplan

when you run the command, it will be executed

(Cloud Posse fork, the latest version, does not have any new features except we added GitHub Team whitelist to detect if a user has permissions to run the atlantis commands. For all other features, you can ask in the atlantis Slack)

I thought when_modified will work even if autoplan is disabled

So I think I came up with a way to authenticate github users specific for terraform applies using a file in /home/atlantis/users with 444 permissions.

https://github.com/nitrocode/atlantis

questions:
1. how do i restrict the atlantis user in the docker container to ONLY be able to read the file and NOT append the file
2. i am whitelisting repos that have access to atlantis plans. on top of that, how do i only allow repo level workflow overrides for a subset of the whitelisted repos?
3. is there a way to perform a different function if a specific tf resource is detected ?
4. using a custom workflow, can I use the @ sign to tag specific people ?

anyone have an example of a minimal terraform policy that Atlantis needs for AWS?

I'm trying to figure out how to get tag based permissions to work, and my original lenient policy is a bit had to prune

minimal Atlantis policy is minimal policy for what you are wanting Atlantis to apply…

Haha yes, true, but in my experience terraform needs quite a few permissions just to do basic operations, even just for state refresh

another question on similar topic: Is anyway using something like an OAuth server infront of Atlantis ?

To do a state refresh it needs read access to the things you want to manage to it 😉

Yes, I believe CloudPosse (may??) do this

@Padarn https://github.com/cloudposse/terraform-aws-ecs-atlantis is opinionated but contains the resources you will need

https://github.com/marketplace/actions/hashicorp-setup-terraform

This is getting closer to Atlantis

using default server workflow and custom repo workflow but only my defined directory has terraform run. all undefined directories in custom repo workflow do not use default workflow.

version: 3
projects:
- name: secrets
  dir: secrets
  workflow: secrets

workflows:
  secrets:
    plan:
      steps:
        - init
        - run: make diff
        - plan
    apply:
      steps:
        - run: "echo 'Apply is disabled for now."

am I missing something simple ?

I’m going to have to fork cloudposse atlantis to fix my needs so I was wondering how can I build my fork ?

this is strange. i have a specific workflow for a specific tf module to overwrite the terraform version yet it still uses the default.

version: 3
projects:
- name: secrets
  dir: secrets
  workflow: secrets
  terraform_version: v0.12.25

workflows:
  secrets:
    plan:
      steps:
        - init
        - run: make diff
        - plan