https://www.runatlantis.io/ logo
Join Slack
Powered by
This message was deleted.
# atlantis-community
s
This message was deleted.
b
• You can simply create a feature branch and run any arbitrary commands as part of the plan command. You could restrict this by enforcing the plan to be approved (plan_requirements), but this is not desired as the nice thing about Atlantis is that the plan is made visible to you as part of reviewing the PR.
• The IAM role or Service Account often has excessive permissions on a higher level, as you roll out infrastructure to various accounts/projects within your organisation. You could also run multiple instances of Atlantis, but this is 1. Costly, 2. You maintain multiple deployments in parallel. 3. It's sometimes hard to split your org in various domains. 4. It's common to deploy infrastructure cross account/project from a single code base.
One way to avoid this: you could manage all the workflows server-side. This way you can assume different IAM roles/Service Account per project or workflow... downside is that you have to redeploy Atlantis quite often, and it's not intended for this.
The only solution (one that reduces internal blast radius) I have seen so far is: running multiple instances of Atlantis. Which I think is not a neat solution either.
• Even if you run multiple instances of Atlantis, the deployment of both nonprod and prod environments will still be performed using the same IAM role or service account. This implies that the IAM role or service account inherently has access to both environments by default.
j
This is a terraform problem not an atlantis problem. Per-environment/atlantis instance you can scope permissions such that the service role is only allowed to assume whatever role is required for your provider configurations to function properly.
But the role that terraform assumes for both provider operations and for remote state management will have widely scoped permissions because it will need to create/modify/destroy cloud resources. There is no way around this. You can configure atlantis such that the server-side atlantis yaml/config is not overridden by PRs/branches.
b
It is an Atlantis problem actually, forcing multiple workflows to run under a single service account or AWS IAM role is not adviced at all.
Many modern CI/CD tooling allow for the use of OpenID to dynamically use credentials per workflow/project/pipeline/stack
But the role that terraform assumes for both provider operations and for remote state management will have widely scoped permissions because it will need to create/modify/destroy cloud resources. There is no way around this.
You can easily get around this actually. GitHub Actions < > AWS OpenID is a great example.
Pretty much like any other modern CI/CD stack.
Many companies will not accept the fact that there's a single SA or IAM role with permissions across environments, let a lone accounts/permissions across projects that are not related to each other at all.
Per-environment/atlantis instance you can scope permissions such that the service role is only allowed to assume whatever role is required for your provider configurations to function properly.
That's not a solution. This means you're forced into running multiple instances of Atlantis. Which isn't a very solid design choice imho. You can probably guess the amount of instances a large enterprise will have to maintain... 🥲
You can configure atlantis such that the server-side atlantis yaml/config is not overridden by PRs/branches.
Is also not really a viable option. Say you would prefer to not have many different instances and try to enforce workflows from the server side config, you'll have to redeploy Atlantis every other day as people add/change the server side config to update their workflow..
j
Cool I give up I guess.
b
Been trying to wrap my head around this issue for sometime already 😞, especially for our larger clients
It's not really a problem in smaller companies with a few AWS accounts or GCP projects. We just see a lot of push back from the larger enterprises, mentioning the above issues
p
I think Atlantis needs another way to allow users to pass/select a way to authenticate against different accounts that does not force them to have one deployment per account. OIDC is becoming the way to do this lately and atlantis just does not support it. I agree with Jason that is a TF problem ( it should support OIDC) but CICD tools as Bruno said have been offering this solution that plugs in very well with TF to solve this problem.
j
p
and TF cloud is basically the CICD tool for TF so there is a link there
Atlantis is basically the link missing for community terraform in this case
✅ 2
s
It is possible to use different service accounts in GCP for different atlantis projects (we use different for test and prod) via server side workflows and env variables - https://cloud.google.com/blog/topics/developers-practitioners/using-google-cloud-service-account-impersonation-your-terraform-code. You can also prevent devs to use 
local_exec
via conftest/checko/other OPA tool
It's not perfect but reduces blast radius by a lot
b
There's just 2 problems with that, 1 the default SA has access to impersonate all of these. So in the end, it's still an open gap which can allow for a lot of lateral movement, and you have to define and maintain the workflows in server-side config - which causes Atlantis to be redeployed from time to time. @Stas Ostrovskyi your suggestion in combination with multiple instances is what we advise at the moment, just to reduce that internal blast radius. It's just not perfect like you said.
s
We have one instance, but I do agree with the general problem that redeploying/updating atlantis is a bit painful.
Open in Slack
PreviousNext
Powered by