This message was deleted.

cc @Chris ter Beke (tagging my colleague for visibility).

It is, might I also suggest maybe proposing an ADR first for context and we can use the meeting to discuss the ADR?

Hi! Thanks for inviting and tagging me @Bruno Schaatsbergen. So first a little of context: we were investigating using Atlantis at some customers at a scale that requires different teams to deploy their GCP infrastructure projects/repositories in a scalable but isolated way. For me this means that a central DevOps/CCoE team manages the Atlantis deployment, and client teams can request their repositories to be 'whitelisted' and automatically be able to deploy to just their GCP projects. Unfortunately this is currently seems not possible without changing the Atlantis server config and re-starting Atlantis, and create a lot of repeated config in the server config. Our preferred solution direction involves GCP Workload Identity Federation (which is based on OIDC), but this requires jobs to not be able to break out and access the OIDC private key that's somewhere on the filesystem. In the code we can see that Atlantis runs a series of

os.exec

commands but these run as the same user/context as the main process, meaning a client team can always create a branch, run some escalating shell commands to gain access to the private key, generate any JWT they want, and gain access to other client's GCP resources. Is there any way that a more isolated job model could fit into Atlantis' architecture (changing user IDs for jobs, changing chroot, running in containers, remote runners, etc.).

So right now with the current architecture, it's not possible to run a more isolated job model. We are definitely thinking about moving to a more "control/data plane cloud-native" model (I put it in quotes cuz buzzwords) than what we have currently which would enable more job models including the isolated one that you are wanting to implement. My focus first has been mainly on the filesystem side of the workers due to problems with file locking when doing Git cloning. But happy to discuss and plan out a proposal on how to further break out certain subsystems of Atlantis to better fit a the new model

Thanks for the response! I would be a strong proponent of a cloud native model where the orchestration plane is separated from the runners. Always happy to brainstorm on that. I'm also keen to get it working nicely in Cloud Run so there's no VMs and VPC to manage 🙂

FYI on this (@PePe Amengual, @Dylan Page) - we found a neat solution in Google Cloud to currently isolate authentication per account/project level. By granting the identity attached to Atlantis only 'impersonation/assume' rights on other service accounts (IAM roles). All the workflows are defined server-side, including a step per workflow to impersonate an identity specifically created for a project.

That is definitely ideal, just requires a bit of configuration with the workflows. I bet we could replicate with the other cloud providers too