https://www.runatlantis.io/ logo
Powered by
Title
e

Ed

03/21/2023, 2:11 PM
Maybe not strictly atlantis question but I’ll try anyway. We are running atlantis for multiple github repos (
x,y,z
) as an ECS task inside AWS account 
A
to create different terraform resources in AWS accounts 
B,C,D
. Can anyone think of a way of restricting certain repos to create resources only in certain AWS accounts, so that 
x
can only create resources in 
B
account, 
y->X
and 
z->D
n

Nataly

03/21/2023, 2:13 PM
I think you may need to run multiple atlantis instances per “permission boundary”.
☝️ 1
Each instance would have a different service account: atlantis X --> B atlantis Y --> C atlantis Z --> D
Or, you can specify the AWS creds in provider config for the end-user file, right?
e

Ed

03/21/2023, 2:16 PM
having multiple atlantises is an option, however the more repos we have the more atlantises we’ll get and this can become hard to manage and sync
n

Nataly

03/21/2023, 2:17 PM
agreed ^
e

Ed

03/21/2023, 2:17 PM
in s3 backend provider config the roles are passed with 
role_arn = "arn:aws:iam::xxxx:role/terraform"
j

Justin S

03/21/2023, 2:21 PM
Can you not just configure that in the provider
n

Nataly

03/21/2023, 2:21 PM
Your concern is that you want to restrict a repo to a particular set of AWS credentials such that it can only interact with that AWS instance. The hard boundary would be separate atlantis instances per AWS instance. However, you can also add a custom server workflow where you have a key/value of repo=AWS instance. When someone plans, your custom workflow will run and you will only pull in credentials (from a secret store for example) for that AWS instance in question.
Can you not just configure that in the provider
Then end-users have control over which AWS instance they connect to
j

Justin S

03/21/2023, 2:22 PM
provider "aws" {
  region = "us-gov-west-1"
  allowed_account_ids = [
    "yyyyyy"
  ]
  assume_role {
    role_arn = "arn:aws-us-gov:iam::xxxxxxxx:role/terraform_infra"
  }
  default_tags {
    tags = {
      Environment  = "dev"
      DeploymentID = "infra"
      Terraform    = "true"
    }
  }
}
then tell atlantis it can only apply mergable Pull's
e

Ed

03/21/2023, 2:24 PM
^ that doesn’t take in consideration repository name where PR originated from
j

Justin S

03/21/2023, 2:24 PM
Thats why you review it.
this is how we operate, the only difference being, our providers etc are all generated from a template.
e

Ed

03/21/2023, 2:25 PM
are env variables available in conftest policies?
j

Justin S

03/21/2023, 2:25 PM
https://github.com/refl3ction/tfgen
so we set the provider 
allowed accounts
variable, and then users generate their provider config so its always correct.
we are a monorepo, but depending on which folder you generate your TF deployment it, changes the account ID you would get for your 
allowed_account_ids
c

Chastity Blackwell

03/21/2023, 2:37 PM
We solved this problem with multiple Atlantis instnaces.
😭 2
I think it's the only way to be absolutely sure there's no chance of your dev instance applying to prod, etc.
n

Nataly

03/21/2023, 5:18 PM
yeah multi-tenancy is hard w/o running multiple instances. The next best thing is loading secrets during application runtime based on repo validation (via an allowlist or something) per plan.
#communityJoin Slack
Powered by