This message was deleted.
# atlantis-communitys
Slackbot
03/21/2023, 2:11 PMThis message was deleted.
n
Nataly
03/21/2023, 2:13 PMI think you may need to run multiple atlantis instances per “permission boundary”.
☝️ 1
Nataly
03/21/2023, 2:14 PMEach instance would have a different service account:
atlantis X --> B
atlantis Y --> C
atlantis Z --> D
Nataly
03/21/2023, 2:15 PMOr, you can specify the AWS creds in provider config for the end-user file, right?
e
Ed
03/21/2023, 2:16 PMhaving 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 PMagreed ^
e
Ed
03/21/2023, 2:17 PMin s3 backend provider config the roles are passed with
Copy code
role_arn = "arn:aws:iam::xxxx:role/terraform"j
Justin S
03/21/2023, 2:21 PMCan you not just configure that in the provider
n
Nataly
03/21/2023, 2:21 PMYour 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.
Nataly
03/21/2023, 2:21 PMCan you not just configure that in the providerThen end-users have control over which AWS instance they connect to
j
Justin S
03/21/2023, 2:22 PM Copy code
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"
}
}
}Justin S
03/21/2023, 2:22 PMthen 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 PMThats why you review it.
Justin S
03/21/2023, 2:25 PMthis is how we operate, the only difference being, our providers etc are all generated from a template.
e
Ed
03/21/2023, 2:25 PMare env variables available in conftest policies?
j
Justin S
03/21/2023, 2:25 PMJustin S
03/21/2023, 2:26 PMso we set the provider
allowed accountsJustin S
03/21/2023, 2:27 PMwe 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_idsc
Chastity Blackwell
03/21/2023, 2:37 PMWe solved this problem with multiple Atlantis instnaces.
😭 2
Chastity Blackwell
03/21/2023, 2:38 PMI 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 PMyeah 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.