0:00 Atlantis is my second favorite spin off of the Stargate series, but that's not what this episode is about. Wait. What was your first? In all seriousness though, David couldn't even stop asking questions because it was so interesting. Terraform automation is a very important aspect of production engineering, so I was genuinely excited. You weren't the only one. Today, we got to talk with one of the maintainers of Project Atlantis, a Terraform pull request automation system. So let's go deep, deep undersea and explore the wonderful world of Atlantis. Not Stargate. Alright. While David is having some tea, we

0:38 are welcoming a new guest today to talk a little bit about the Atlantis project. Pepe, do you want to introduce yourself and tell us a little bit about Sure. I'm, my name is Pepe. Well, it's my nickname. My real name is Jose, but everybody calls me Pepe in the tech industry. So let's let's let's give it a Pepe. I have been with the Atlantis project for about four years almost, I think. I am not the original developer of the Atlantis project. I inherited from, Luke and Mishra, which both work in HashiCorp right now. And I became involved with the

1:11 project due to the fact that I needed a feature really badly. And I was like, I need to do this. And I used to work in Sonatype, which is a has a lot of open source projects. And basically they support me to introduce the feature and somehow I end up with owning the project with Dylan and Chiryu that are the other core maintainers of the project. Yeah. I know you said HashiCorp. Yes. Yes. Yeah, yeah, yeah. I was gonna say, I know you said HashiCorp, but all I heard was IBM. Brutal, brutal. There was a big discussion at

1:43 some point. We were kind of nervous at some point about it because the Atlantis was created in Vancouver, literally half a block away where I used to work. So maybe me and Luke and Mishra eat it in the same restaurant in the corner of the Raywall Street because it was created by Hootsuite. So when they were in Hootsuite, they created Atlantis. And then they open sourced it. Hootsuite was happy to do that. And then it became an open source project. And then Mishra Luke moved to HashiCorp. And when I joined the Atlantis project was a bit it

2:17 didn't have much activity because where I used to work in Sonatype, we have a lot of open source libraries. I ask what if we, because we're using Atlantis, what if we actually fork Atlantis under Sonotype and we maintain it and they were okay. There's a bunch of Golang developers there. And I was not a Golang developer at all. And I'm not a Golang developer. I can't call myself a Golang developer. And so I learned Golang just to build this feature and that's when basically that spark kind of like looked to add, try to find out

2:50 more contributors. And so this was basically the first time that Atlantis ever had external contributors except for Mishra and Luke. And that's how we became part of the project. And well, a few years after that, after the change of license of Terraform, we got an exception from HashiCorp for because we have the binary of Terraform within the Atlantis image. So we were not sure if that was in breach the new license. And then at the same time, that's when we start asking the question, should we move it to the CNCF? Should we apply to be a CNCF project?

3:33 And that's when basically Luke dropped from the project and give us ownership of the whole project to the three of us. Awesome. For anyone listening, let's make two assumptions right now. One, they know what TerraForm is. And two, they don't know what Atlantis is. Can you give us the kind of the rundown of what is Atlantis and how do people integrate it? Yeah. So Atlantis is basically, I would say maybe one of the first, if not the first, GitOps workflow integration with Terraform. So the idea is that developers don't have to go and use, you

4:09 know, their local environments or a local or another tool to run their Terraform workflows to deploy their infrastructure. And was moving that responsibility or that tooling to the left, closer to the developers. So Atlas integrates with the VCS, which could be GitHub, GitLab, Azure DevOps, GitT, and Bitbucket. And basically you create a webhook configuration in your repo and then the user, the developer can just basically interact with Atlantis commands and so comments within the PR and Atlantis will respond with the Terraform plan against the workflow that is defined. Atlantis can do it automatically like if you have a few Terraform

4:49 files in the repo, it has auto discovery, auto planning and it discovers those files and then it will basically tell you, hey, here's your plan. And it will create a formatted comment within your PR so you can see it and then people that review the PR can see it too. And then it's like, this is what supposed to what TerraForm wants to plan. And then you can have a better idea of what the outcome of that PR is going to be. So then you get kind of like a sense of what it's going to look like

5:20 in the current infrastructure after the PR is merged when the deployment happens. So all the interaction is based on command. So you do Atlantis plan and then you get the comment. If you don't have, if you have auto plan enabled, it will do it by itself. And then if after the reviews, after rules that you have in your repo, Atlantis will look at those rules in the VCS and then it will say, okay, well now this is approved, it's ready for merge. And then you run Atlantis apply and then it runs Terraform apply for you. And Atlantis

5:50 is not a wrapper. Atlantis just runs your binary of Terraform. So people use it to run CDKTF. Some people use it to run TeraGrant. Some people use it to run Atmos from Cloud Policy. So you can actually run anything that outputs a Terraform plan at some point. So you can glue a lot of scripts in between, run policies and a bunch of other things. That's basically what Atlanta said. You can extend it quite a lot, but in an essence it's basically GitOps interaction with your terfont workflows. I I never knew that angle. I use CDKTF

6:24 quite a lot these days, and I like I've not used it in production, but I like the Atlas project and it's use of HTL for database schemas and migrations. Mhmm. And I don't even think for a second that you could run Atlantis as your kind of CICD glue at that point to get kind of visibility into what is going to change. Yeah. And I just want to focus on kind of that one statement. It's like, for anyone listening to that description, was great, right? The take home is Atlantis seems to be that window into what will change if I

6:51 merge this pull request. Is that that correct? Exactly correct. Yeah. Yeah. Yeah. It's kind of like the snapshot of like, what is this PR going to change of my infrastructure? Obviously, is we can get into discussions about, you know, apply before merge and apply after merge, which Atlantis is applied before merge, which has these drawbacks. But basically, at the point that the command was done, the infrastructure looked like that and your code was trying to change that snapshot of time of the infrastructure in that moment. Yeah. I guess this goes down to that wonderful naive assumption that many people make.

7:28 If they merge a pull request, the code that's going to end up in the main branch is the code that was in the PR, and that's not always the case. That's correct. Because in the between, this kind of like tab up versus spaces conversation. In any tool that relates to Terraform due to the state and how the state works, because the state is not a synchronous entity where by itself will actually check the status of the infrastructure is only by triggers. The any tool that uses a GitOps flow will have a delay between what reality is,

8:02 which is your infrastructure, live infrastructure with the VR. So if someone goes in and has the ability to change manually something that you want to change in your plan, that plan is already out of date. Damn those click offers. But anyway, you don't work for IBM, right? No, I don't. I don't. I work for a consulting Cool. So I can say, does Atlantis work with OpenToFu? Yes, it does. Yeah. Yeah. Yeah. Yeah. So we we added OpenToFu support. Actually, this is a bit of a misconception about Atlantis or maybe it's not well documented, maybe it's our fault too. So you

8:39 can run anything in Atlantis that produces Terraform plan output, a plan file. As long as it runs Terraform, you generate a Terraform plan file, you can do anything you want. You can create a Jira ticket in between and then run Terraform. You can do all the stuff because you can add your custom workflow with your custom script. A lot of people even use connections with AD to figure it out if the users are part of a group in AD before the plan gets run and a bunch of things. You can customize this really heavily. So

9:09 you can run anything. So before we actually, we had official OpenTofu support, people already were using OpenTofu because you can customize the workflow to just run the Tofu binary instead of the terfone binary. So that there's a blog post in our site about that. And then we release Open Tofu official support. And what I mean by official support is that now that Atlantis is able to download automatically the version of Open Tofu that you describe in the workflow required versions. So that's the difference between kind of like official and non official support is that we

9:45 were out to download because we had that capability for Terraform and we want to offer the same in OpenTof. Do you find that you have like some usage stats at this point where you can say like, okay, you know, 50% of people are using OpenTofu versus I'm actually kind of curious if you have Actually, I do. They're not up to date because we did a survey a while back. We I remember sending these screenshot to the OpenTofu Slack channel because at that point OpenTofu was, I can't recall the version of Open Tofu, but there was about 20 or 30% of

10:30 the people were using our Open Tofu at that point already. So that's, that's way higher than I was very surprised because at that point, OpenTofu was like super, super early stages and people were already using it. I was like, wow, that's that's crazy that a lot of people are using it. So, yeah. Yeah. Alright. I'm going to ask a flippant question. Please don't hate me too much. Right? But I Atlantis is a wrapper, if you will, of TerraForm or Open Tofu, etcetera. Uh-huh. Basically, it just gets planned out and then post to a comment. That's right. But you've been maintaining this

11:02 project for four years. I'm assuming it's got a forward trajectory. Things are changing. Like, is it not done? Like what comes next? Like what are you Yeah. That's a hard question to answer right now. We literally have a meeting last week or two weeks ago to talk about the future. This is a problem. We are all working on we have our day jobs as many, many or pretty much 99% of every contributor on an open source project, they do not work a hundred percent of the time at the project. So, and a lot of us have changed kind of like

11:33 responsibilities within our jobs. So, or we are more busy than before or less busy, but we need to focus on learning something new or whatever. So we are all kind of like in transition period where, we are trying to figure out what are we going to do. There's new people that join us and they are core contributors, not yet maintainers. So we are hoping that they will have the time to join us as a maintainer. There's a lot of commitment. It's a lot of code. We support all those VCSs that I mentioned. It's hard to keep up with the API

12:05 changes of the VCS. And then on top of that, try to move towards the future. The future of LightLand is right now. The short term feature is that we are going to release version one point zero as official. Due to the fact that it has been used in production for many, many years already, but we didn't ever move to basically follow Semper correctly. We are already in production, therefore we should have in version one point zero. But for that we need to do some work because, you know, the docs, for example, don't reflect versioning of the features. So we want to

12:40 reflect that. We already deprecated a bunch of old, configs and parameters that we don't support anymore. So we did that work. So there's a few other things that we need to do to get to like release one point zero and then two point zero will be basically what we would like to see in the future. But for that we need a lot of more maintainers to help us out. So ideally what will happen with Atlantis is that it's going to be a queuing system for PRs that will be synchronous to the cluster. So ideally what will happen is that we

13:14 will use something like, I don't know, Teporo or something like that, that will be able to manage queues of PRs, incoming PRs for multiple VCSs at the same time. And then they can basically have worker nodes that will run the plan and there will be some sort of metadata share storage where if the node goes down, we still can find information and so on and have statuses globally across the whole cluster, which is not true. Right now you can run multiple Atlantis instances in HII mode, but it's a bit tricky and a bit slow because you need shared storage and things

13:53 like that. So hopefully we can get to that point. Interestingly enough, the Atlantis project was a huge amount of contribution from Lyft. There were two developers from Lyft. Lyft used Atlantis quite heavily internally. And a lot of the features, some of the features that we have right now, for example live logs and things like that, are actually due to their contributions. And at some point they wanted to actually create something called an Autelus under our repo and to be able to use Temporal as a queuing system for Atlantis. So that was what they were building inside. So we were

14:32 basically going to move towards that. But then there were some disagreements between HashiCorp and then that could not happen. Hopefully, you know, in the future that's where we will get to. Where we can have like a more distributed system for Atlantis instead of having like Atlantis actually scales really well vertically. We have people that have, 500 PRs a day going through an Atlantis server and only one Atlantis server. So for multiple environments. So it really, really is really performance. But obviously all of that depends on how you structure your data from projects and so on.

15:07 Yeah. I guess I wanna make sure I captured the kind of problem statement there correctly, right? Like GitHub now has merge queues. So we have some sort of guarantee that well, we do have guarantees that pull requests be merged in a certain order. So it's not the TerraForm apply, I think, that is causing problems here, right? Correct me if I'm wrong. The challenge that you have and why horizontal scale and temporal may be really useful is that if you've got multiple PRs being opened at the same time and they're all running a TerraForm plan, those will be very different depending on when

15:38 they're actioned sequentially. Or even if they happen at the same time, the plans would actually be incorrect. Yeah. And that's the problem that if you push this, well, I guess if you push it through temporal or some sort of queuing system, still doesn't give you a guaranteed output, but it's going be a more consistent. I don't know. That's a tough problem. Yeah, the problem is mostly which Atlantis server picks the BR. And if that Atlantis server dies and then someone runs another command, will we have enough information to continue the work that was lost? Or

16:12 the other problem is that parallelism in terraform plants is hard within one specific instance. Like if you run multiple plans of the same repo in your computer, it's actually tricky. You could potentially lock the project completely and then the next person will not, if you have login enabled, will not be able to use it. You can use WorkSpaces and do things like that. So so there is a bunch of problems that the queue and and worker nodes could solve that not only pertains to the Terraform plan in itself, but but to who manages that request at that particular moment. And

16:50 if we can run multiple PRs from the same repo, for example, in multiple different servers, you know, and then synchronize that metadata back. Okay. So how deep is the GET and GitHub integration then? And the use case is the one that I kind of just talked about. If we've got two pill requests, they run a plan and then one gets merged. We're now at the point where pill request B is out of sync with the main branch. Yeah. I could go to the pull request and say rebase, which would trigger the rebuild because the actual

17:18 pull request was updated. But does Atlantis have enough understanding to block or at least warn the user before merging that pull request? Well, that would be very tricky with multiple servers. So that will be a challenge if we move to that worker type of node, no, that would be very tricky. We have different modes of repo settings for like divergent and so on. I will say that they are not as stable as you would think. Or I wouldn't say not as stable, is that the definition of divergent for certain people is different of what we

17:49 offer in the code. And that's where it gets a bit tricky. And so, yeah. So the problem about merging or the workflow, how you work with your repo will directly affect how, you know, the multiple worker nodes will interact too. So those all those kind of like design decisions are going to be really hard to get there. But I mean, it is possible. So it's a matter of like having enough people to like, you know, sit down, write it down and test it and figure it out. But we are not the only ones that, you know,

18:18 want to see something like that. A lot of people, there is a huge issue in Atlantis. I have been there for many, many years of people talking about how can we get Atlantis to be a real instead of, you know, having to do this kind of like shared storage and we have ready support for locking and some metadata. So it kinda works, but it doesn't actually do it in a huge scale for like people that has, you know, 500, a thousand PRs a day from multiple teams and things like that. So that will be the goal. Yeah. But it's going to be

18:49 tricky. That's for sure. And the multiple VCS, thing is it's a huge deal for us. You will not believe how complicated it gets from one VCS client library we have to the other one. So from GitLab to GitHub. What is a status of a simple status. What is done status? How is defined within the VCS? It's always a problem. And what consists of mergeable PR within GitLab, Azure DevOps and GitHub? They're totally different. So that part is actually really hard. We would love to see more contribution from the VCSMs themselves into Atlantis, but that's a hard one. We do have contributions from

19:30 GitLab actually, because GitLab uses Atlantis internally. So every now and then we actually do have PRs from GitLab going into change certain definitions because the API change and so on. So, yeah. And another part of the two point zero and the feature is like create a pluggable PCS interface so that people that has other type of PCSs or they want to, you know, for example, play with version two of the GitHub API or GitHub API can do it easily without breaking the core. So, that's another thing that we are thinking about. So, many, many things in the list of,

20:08 like, what we would like to see for two point zero. So, I'm gonna be the one to ask it because I know David is thinking it. Is Rust anywhere in that conversation? Mostly I'm trolling David, but you know. Yeah. I asked that question not long ago to the other core contributors and we were talking about it. I guess the answer is kind of simple in a way if you think about it because we are a CSCF project now and we are moving to the incubation project and then hopefully at some point we are going to be released as a CNCF

20:39 project. The ecosystem in the CNCF is Golang and that's a simple answer for Yeah, so if Rust would have had a major, I guess, appearance within the other CNCF projects, it will be an easier sell for in that case. So, and there is a lot of things that we are within the ecosystem of the CNCF that support, I guess, you know, Golang more than others. So if I was going to maybe ask for help for something within Atlantis, which is really in Golang, I might have more luck finding someone within the CNCF to help us out than

21:21 compared with Rust. It's a choice. It's a total choice. I mean, don't have to write it in Golang if you want to do it in C. Mean, there's a lot of stuff that are written in C and other languages, but Golang is the main language within the Censor projects. I have thoughts on that, but I'll say that for later. I mean, you also are consuming Terraform. I'm assuming as a Go module, right? Know those No, actually download the binary. No, we download the Oh, okay. So that's when Terraform got changed in license, that's why we

21:54 didn't have an issue HashiCorp or one of the reasons, but yeah, so we just download the binary. That's what we do. And then we just run against it. That's all we do. All right. Well, I'm going to come back to some more hard questions then because Atlantis is obviously a very cool project. It's in the CNCF. It has, you know, of contributors, power of momentum to one point zero and the future two point zero. Right? But we're talking about a project that has the ability to execute TerraForm, which is obviously downloaded as a binary. So

22:26 there's one security concern there. I'm sure there's checks and balances in place, but, know, we'll get there. That also has the ability to run against all of my cloud native infrastructure, whether that be on AWS, GCP. Yep. Any integrations, Datadogs, New Relics, anything I can use Terraform these days, which is pretty much everything. So you've got access to all of my credentials, security concern. And we've put this into a repository, which may or may not be a open source publicly available repository with CICD runs with log outputs and the ability for people to execute commands or comments, which I'm assuming that's how

23:00 Atlantis is orchestrated. Security concern. So maybe you can guide me through what checks and balances are in place to make sure that Atlantis as a secure project for me to run-in my production infrastructure, whether it's open source or not. Yeah, I think that the official answer is you need to follow the cloud provider guidelines or security to when running any telephone code. Doesn't matter if you run an Atlantis. So those guidelines need to be already in your project to be secure because we run whatever you want within your terraform project. So if you're running local exec and then

23:38 doing Bitcoin mining, we can't stop it. That will be in your code within your terraform project. So after Atlantis runs and gets the credentials somehow for the to pass it to the provider, kind of like that's kind of like the first big security problem that you want to solve, then we run any code that is there. So it is crucially important that whatever gets to the repo, it is obviously has some sort of check and balances within the company or the project or whatever is public or not. And that the code is, you know, set

24:16 to be safe. And for that you can use any tools for IEC, you know, security checks, you know, static code analysis tools like Snyk, Fossa or whatever supports Terraform. And after that then it becomes kind of like an interaction between how do you deploy Atlantis into the cloud provider and how you are interacting with your cloud provider. And that is where kind of like the well architected framework type of doc will come into consideration and then realize, okay, how is it safe what is the safest way to pass to a CICD pipeline credentials to then run Terraform? And Atlantis will fit

24:55 in between there. So usually what people will do, will deploy Atlantis in GCP or Azure or AWS and they will use role assumption. And then the role assumption may some people use a centralized account, management account where they have an Atlantis server or deployment that basically has good mode to assume roles everywhere. Then their responsibility of having the roles set up properly so that you don't allow all the services, for example, or all the Lambdas and you actually create your role policies to constrain the least access possible is the responsibility of the person that, you

25:38 know, is maintaining the REST account. So that's why I say it's not just Atlantis, it's actually far more important than how the project is being built. We think with like the security constraints and recommendation of the cloud provider and how the cloud provider recommends you to then assume those different role levels to then interact with, so that you can interact with the cloud provider. Atlantis does have some checks in the sense of like, for example, it doesn't allow you to bypass or to traverse your directory where the BR is. So because at some point there was

26:19 the possibility to be able to graph files outside of your repo. So we have now a setting that defaults to only allow the PR repository to be looked at. And if you want to inject files, there is other methods to do so. But they would only be pertained to that checkout. Because Atlantis, it does is when it gets an event, a webhookit event, the first thing it does is checks the code of that repo, that PR, that commit hash. And so it downloads the repo, creates a repository structure within Atlantis and that's where all your code lists and all the

26:50 commands live and where the plan file is going to be. Everything is there. So now you cannot obviously traverse in between directories. In very old versions you could potentially do that. And then one thing that I will say that Atlantix could do better and that we don't really have a good way to do so. A lot of people solve these problems with policy as code. So we have policy checks, So you can run conf test policies against your code. So then you can check against provider versions and what kind of providers are allowed because we have a mechanism called free workflow

27:26 hooks where you can run any type of tooling or script before Atlantis actually runs. So then you can do all those checks yourself. But it will be nice to see, for example, that we add some sort of way to list the providers that are allowed to run within Atlantis and then Atlantis will actually not run that project if it has those, kind of like an extension of the policy checks, but in an easy configurable setting. We don't currently have that. And that has been kind of like one of the things that's like, hey, it would be nice

27:57 if we could potentially do that because one of the biggest issues in, I guess, that I see as a consultant and I have seen it from comments in the Slack is that they have the Atlantis server, they have this, all this set up with all these roles and permissions. But now anyone that creates a PR can add a provider or can add a new resource that will execute something and they want to not allow anyone to do so, but they don't have those capabilities maybe at the VCS level because they don't have admin rights to

28:28 that or whatever, but they want to do it in the Atlantic side, but they can't. So that's when they get crafty and then create a pre workflow script and so on. So I think that there is more work to do there. But like I said before, since Atlantis is just runs your binary of terform, I guess the best way for you to accommodate for any security issues is to actually download, maybe create your own image, put all the tooling that you want to wrap around your Teflon projects with. And then maybe if you want, you create a custom

28:58 workflow that will run those tools before your project actually runs through Atlantis. And then you can kind of like avoid some of those kind of like middleman injection attacks, let's say, if we want to call them that way, to avoid those kind of like raw user issues, which are more common than not actually in all the GitOps tooling. So, yeah. Interesting. That's a great answer. You covered a lot more there than I was expecting you No, no, that's great. Right? Because what we want is people to be, we want them to be excited by the project. We want them

29:34 to get value from it. And from that, you need to make sure that their security posture is in the right place and that they're comfortable with this kind of workload running. Right? Because the more automation we bring, the more that attack surface expands. Absolutely. Yeah. But let's let's assume people listening. This sounds great. I I'm happy with my security posture. I wanna start running this. A couple of times now you've mentioned the concept of an Atlantis server. And I wanna just understand, is that a prerequisite for people to get started or can they just use a GitHub action to run some

30:03 sort of Atlantis binary? Like, what is that getting started process? We actually do have in our survey, we do have a lot of people that wants to see an Atlantis GitHub actions, but we don't have that yet. So Atlantis is a binary that you need to run listening into a port, to listen to, webhook requests. So, no matter where you run it, some people have run it in even app run and things like that, you it has to be listening as a D1 somewhere. So, most probably most people use container to do that in any type of flavored cloud,

30:38 flavored service that can run a container, which are many. And we do offer a help chart for people that are running Kubernetes so that they can install the help chart. So, at the end of the day, you have to have that this binary running and listening import forty one forty one, which is the default. And then that will become your Atlantis instance basically. And you will have to configure that your Atlantis instance to be able to fulfill kind of like the forecast of, you know, PRs and plans that you might have, depending on the size of

31:11 your project. And size is a word that is used very widely within GitOps, but there is a size of Terraform project that is very important to be able to size your instance or your server. So can you run Atlantis using Atlantis? Is that what I'm hearing, basically? No. Well, I'm controlling a little bit. No. No. No. Actually, that's a good question. You so funny enough, a lot of people do. So, a lot of people have, for example, help chart integration in a pipeline in Terraform that then updates itself. Great. Okay. So, yes. I had to ask because

31:52 I thought that that would be really entertaining if it's true. Yeah, yeah, Actually in many projects that I set up, Atlantis was basically resource zero of the infrastructure and it will run within this account that I was mentioning before that will assume roles in all the different accounts. And Atlantis will actually create the first resources in every single account. So in a way Atlantis was the bootstrapping of all the other accounts. But at the same time I needed to update Atlantis after the accounts were created to like update maps and things like that. And basically you could

32:24 potentially run-in the repo Atlantis plan and you will actually update itself with the new values. As long as these are not destructive things that you're doing within the Terraform code, then it should be fine. Otherwise you will destroy itself. That could happen. It's potentially possible. I think I have one more question. So again, under the assumption, the interest of the audience has peaked. This sounds really cool. Let's assume there's tens of people that go, I wanna go do this tomorrow. Is there ever a use case or ever an instance where you would tell any of

33:00 those people, no, Atlantis is not the right project for you. They should all Terraform be under management of Atlantis, or is there way until you have these certain constraints and then it becomes important? Yeah, that's a very good question. You weren't really planning on having this tough question on the podcast for you. You're just too confident. Was like, he's getting the hard questions today. That's a very good question. I think that is not an Atlantis responsibility. I think that is a business decision, security constrained decision within the person's project, company project and so on. You take that decision before you use Atlantis.

33:39 And then you decide if you want or any type of key of automation tooling connected to that project. I mean, for example, we could potentially say that a project that is creating new, for example, let's let's talk about it because I'm more familiar with it. But imagine that I'm creating the AWS accounts and I'm setting up SCPs, service control policies within the account and so on. You might want to say, you know, at some point or maybe the security team will say, you know what, we want to manage that. But we don't want that as a GitOps

34:16 approach because we run those so infrequently that we will prefer to actually do it in a pipeline that is very simplistic, but we don't want Atlantis in between. We want to provide to Atlantis the required access and that's about it, which is more like in a brownfield scenario. And that happens quite often where, where the security posture of the company doesn't allow, you know, you to run semi automated tools or a high security or high access level telephone project. So that depends mostly on that. That you cannot run anything at that. You can run absolutely every single piece of code in Atlantis.

34:55 And I have done the same kind of like workflow of creating SCPs and creating accounts and so on within Atlantis. But that Atlantis basically had got access. If you're okay with that, then that's fine, which is true to every other project out there, Terraform Cloud, Terra made anything that can automate Terraform workflows. Okay. I've got one more now just because we're talking about gut access mode. Right? Let's say I mean, if they pop in my head, I'm gonna ask them. That's that's my to my own detriment. But if I run Atlantis, let's use AWS because that's

35:30 the one you just mentioned. Right? And I I assign a role to that instance. I'm assuming I can use, you know, you said assume role a couple of times now. Right? But workload identity, I can say this workload can assume this role because it is this workload. So, I mean, again, we're you know, it's not deflection, but when we talk about the security of Atlantis, it does just come down to good cloud practices, the standard things you would have to do regardless of whether Atlantis or not. That's so correct. So, it's not that's why I said, you know, that's what

35:56 people, we get a lot of questions of companies like they send me a Slack messages directly. Hey, you know, we want to use it, but it's not PCI compliant or it's not HIPAA compliant or is it, but that's not, is it the advantage responsibility? What does it, the line needs to be drawn? And a lot of people actually get confused. Oh, but Atlantis will have all these access. No, no, no. You are giving access to Atlantis. That just doesn't have any access. It doesn't want you to set up AWS. We don't have an AWS client within the library. We

36:26 just run Terraform and your Terraform that is in your binary. So if you create your image, you have to put Terraform there. Otherwise it doesn't run. We don't have a client built in and go. So, and that's where people actually get confused because they think that Atlantis is the one that has access, but in reality it's the same as me as the administrator, the DevOps person or platform engineer that has access to run terraform is the same deal. It's not different. The difference, I guess, is that that automated tooling, which in this case will be Atlantis,

36:55 have more most probably will have more access than you running locally. But would be it. One thing that you could do in Atlantis, which we recommend most of the time is to run multiple Atlantis installations or containers, the servers in different accounts. That's for sure we always recommend. If someone asks, if you really want to make the blast radius of access, I guess, the Atlantis server smaller, just run an Atlantis server in each account. So that then we have a way in Atlantis to configure multiple Atlantis servers using the same repo. So if you have a mono

37:33 repo to do all those things, you can actually use Atlantis configuration to be able to say Atlantis dev plan and then it would just run plan on dev and so on. And then you can apply and follow approval process and approval rules within the repo. That will be actually the best approach and a lot of people do that currently. Obviously it depends on your VCS, if it supports multiple webhooks and things like that. Some VCSs are different. You know, GitHub and GitLab, for example, are, you know, that's totally normal and people do that. I mean, I'll only challenge one thing there.

38:10 It's not the best approach. The best approach is to have no infrastructure and no code. Correct. Yeah. And the best security is disconnect the RJ45 from your rack. That's it. Pull Exactly. That's it. Just turn it all off. And I think on that note, we have had a wonderful episode. So any last words for our audience before we let you go today? Well, I guess that if anyone wants to use Atlantis and or has any questions about it, we are always very active in the Slack channel and the CNCF, in the Atlantis channel. So you're welcome to join,

38:39 ask questions, try it out. I would try to, you know, guide you within my time limits and anything that you're trying to do, and we will do the best to help you out, you know, with the community. Yeah. Very nice. Well, thank you so much for joining us. We're really happy to have had you. Yeah. Thank you for the interview. That's amazing. It was pretty good time. So thank you. Thanks for joining us. If you want to keep up with us, consider subscribing to the podcast on your favorite podcasting app or even go to CloudNativeCompass.fm.

39:11 And if you want us to talk with someone specific or cover a specific topic, reach out to us on any social media platform. Until next time when exploring the cloud native landscape on three. On three. One, two, three. Don't forget your compass. Forget your compass.