[PROPOSAL] Allow specifying environment variables in workflows

[pratikmallya]

As a user of atlantis, I want to be able to specify a custom list of environment variables and use the default init, plan, apply steps. This allows me to not write custom commands when running terraform. Specifically:

• atlantis does some parsing of the apply output that makes it much cleaner and I want to reuse that instead of writing custom bash/awk scripts to do the same
• the atlantis.yaml file looks much cleaner without custom commands

It also seems like there are many related asks to this where the users seem to be asking for the ability to specify environment variables.

My proposal:

• add a new field called envs to the Step type which would hold key value pairs specifying the environment: variable mapping e.g.

workflows:
  team_A:
    plan:
      envs:
          GOOGLE_APPLICATION_CREDENTIALS: GOOGLE_APPLICATION_CREDENTIALS_TEAM_A
      steps:
      - init 
      - plan
      - apply
  team_B:
    plan:
      envs:
          GOOGLE_APPLICATION_CREDENTIALS: GOOGLE_APPLICATION_CREDENTIALS_TEAM_B
      steps:
      - init 
      - plan
      - apply

[pratikmallya]

@lkysow / @majormoses this is something I was planning on doing but just wanted to get feedback on whether this makes sense or if there are better ways to do something similar

[majormoses]

So the idea would be you use something like chamber to execute the atlantis process with all the env vars exposed and then create a mapping to tell each team which to use?

I like the idea but without strong stronger protections such as RBAC there is no way to enforce it so team A can't see team B's credentials. I think it would be better to run multiple instances of the atlantis process for each team, rely on an encrypted terraform vars file, etc that way if a team/project was compromised they would not be able to exfiltrate all the secrets. Otherwise we start treating atlantis like a secret store/vault and I think it would be better to implement integration with various vaults (hashicorp and aws ssm for example) and allow admins to specify paths that each project can access based on a namespace.

[pratikmallya]

I like the idea but without strong stronger protections such as RBAC there is no way to enforce it so team A can't see team B's credentials.

How would team A see team B's credentials, when they are stored in files on atlantis and nobody has access to atlantis except the operations team?

The use case here is to have a single atlantis instance and use a monorepo to hold all the teams infra and use a CODEOWNERS file to restrict access. Running multiple atlantis instance is a huge PITA; devs teams don't care, they just want a working atlantis.

[majormoses]

How would team A see team B's credentials, when they are stored in files on atlantis and nobody has access to atlantis except the operations team?

Most constructs in atlantis have a repo config which is part of my concern. If it's server side only it limits its exploitability. If the repo can say for GOOGLE_APPLICATION_CREDENTIALS set it to TEAM_B when they are on TEAM_A and then use a data source or output to exfiltrate the credentials.

[YesYouKenSpace]

Can this be achieved with https://github.com/runatlantis/atlantis/blob/master/CHANGELOG.md#v090 ?

workflows:
  env:
    plan:
      steps:
      - env:
          name: STATIC
          value: set-statically
      - env:
          name: DYNAMIC
          command: echo set-dynamically
      - run: echo $STATIC $DYNAMIC # outputs 'set-statically set-dynamically'

[lkysow]

Yes, you're right, this does close the issue!

workflows:
  team_A:
    plan:
      steps:
      - env:
          name: GOOGLE_APPLICATION_CREDENTIALS
          command: echo $GOOGLE_APPLICATION_CREDENTIALS_TEAM_A
      - init 
      - plan
      - apply
  team_B:
    plan:
      steps:
      - env:
          name: GOOGLE_APPLICATION_CREDENTIALS
          command: echo $GOOGLE_APPLICATION_CREDENTIALS_TEAM_B
      - init 
      - plan
      - apply

[lkysow]

Closed by #751