Terraform Security: Attacking and Defending Infrastructure as Code

thank you all for for coming out and listening to my talk I'll try to keep this pretty quick so that uh you know you're not starving so today I'm talking about terraform security attacking and defending IAC so quick introduction I'm Mike mccab uh president and CEO of cloud security Partners um we help people with cloud thank

you all right good for now uh yeah sorry so I'm Mike mcabe um president of cloud security Partners so we do a lot of work in Cloud security a lot of that is around infrastructure as code which I'll talk about and as a security person trying to to help people be more secure I'm very passionate about this topic and I'll get into why that is so what are we talking about uh how many folks are familiar with terraform oh okay handful that's good so it's infrastructure as code obviously um it makes your infrastructure codified and consistent um some of the benefits of that are you know we traditionally did things like click Ops which is going

into a console creating your ec2 creating your s bucket naming it you know Mike 123 and then moving on to the next thing so we have all this kind of um spray and prey with infrastructure traditionally we had people just setting things up without having the right settings and we mve to an infrastructures code based deployment because it gives you centralized deployments so you have one place to do everything versus everyone going into the console and uh and deploying things you can deploy consistent infrastructure you're using modules you're using you know guard rails to keep things enforced um it's all in code so that means all of it's in GitHub or bitbucket or gitlab um

if you're zip filing zipping files and setting them around things have gone wrong but I've seen that more recently than I wish I I had so and the big thing is you can apply security controls uh for preventative measures at that level some of the challenges though with infrastructure is code is terraform and other pipelines just like we see with app pipelines are they're given a lot of permissions if you go and look at your terraform pipeline or whatever it is cloud formation um uh whatever you're using and it has the admin access role for AWS you need to start working on fixing that right now because it shouldn't have that much access but often people give pipelines more access

just so they can get at the job done um and not figure out what's the least privileges I need to give it because um it just takes a long time to do that it's it's admittedly hard to do terraform has a few has quite a few ways to do remote kit execution which I'll talk about some of them it's also a great way to gather data about an environment because terraform is a stateful tool which I'll get into um it has all the information about what the environment looks like right now there's also ways to bypass security control so even if you do have security controls in place there are ways to bypass those to keep doing malicious

activities so our experience in this um we've worked with a lot of large companies moving their infrastructure to a terraform or cloud formation based deployment sack away from traditional way of doing things centralizing their deployments in one place so that teams have one tool to adopt to to have the kind of companywide way of doing things along with that we've written thousands of rules literally thousands of rules across different languages to um basically enforce those security guard rails those compliance rules and what we see I I do this with our customers pretty regularly is we'll go into their csbm their wiz. their you know whatever tool you have it doesn't really matter we'll look at all of the resources that

are deployed through these pipelines and we'll see almost no findings you still see some patching issues you'll see some stuff that happened post deployment maybe but from the cloud configuration perspective we see almost no findings if this is done well and anyone who has a csbm tool that's Cloud security posture management it's your you know whiz or divy or whatever it is um those usually are lit up with thousands of findings if you have hundreds of hundreds of accounts or even dozens of accounts you have thousands of resources each of those resources has you know 3 to 10 to 30 uh configurations that are security related and you can just imagine at scale how many issues you're going to

have uh if you don't have something preventing these kind of issues so the reason why I'm so passionate about talking about how security people can start using these tools to be more secure um and be more just aware of how they work is because you can have such powerful preventative controls so for anyone who hasn't seen what these pipelines look like it's it's very similar to app pipelines it's not you know completely different it's not a different uh Paradigm exactly on the left side you have your source code management GitHub gitlab whatever it might be um in this example I'm using terraform Cloud which is just terraform Hashi Corps terraform um cloud-based pipeline they also have an Enterprise

product or you can just use terraform open source it is a free and open source tool it's sort of not exactly purely open source now but it's still free um and then on the right side you have your Cloud providers you can even have you know kubernetes on Prem being deployed through your pipeline you can do a lot of configuration through terraform doesn't have to just be AWS and Azure um or gcp so but it's a typical pipeline it's nothing too out of the ordinary dev's right code they push it to the left side the pipeline picks it up pushes out the resources to um to the environment so it seems like a lot of

folks here are already familiar with it but just to give kind kind of a high level overview of how terraform actually works because it is important for the security part of how uh of how security controls and how malicious actors can bypass them is is how the actual fundamentals of terraform work so it's a stateful it's a stateful tool which means we're not just running an a you know command line script to create an ec2 we're running a terraform plan and apply which then creates a state file which says what you just did and what the state is so how ter does that is kind of two steps um you have the terraform plan which is you write your

terraform it can be super simple you run terraform plan it goes out to the cloud provider it says what am I doing based on what this person just wrote am I creating an ec2 am I modifying an ec2 it creates that plan which basically says before I do um or when I do the next step this is what's going to happen it could be a delete it could be a modify it could be a create so that's when it creates the dependency tree it says okay I have to create this KMS key before before I can reference it to this S3 bucket um and it tells you basically what you're about to do which is very

important uh because you definitely want to do an apply and review what you're going to do before you kick it off because you might just tear down your whole PR environment if you're not paying attention and a big part of that is it determines unknown values um when it creates that dependency tree if it doesn't know what a value is because it doesn't exist think of like Arns for new resources you don't know what that Arn is until it's created so you can't you can't reference that value it basically puts in placeholders for those values and says we'll know this once the apply uh is done and the resources is created so that's very important from a security

perspective which I'll get into in a little bit and then the second step is the terraform apply which is the actual you know rubber hitting the road where it's going to reach out to AWS whatever cloud provider it's going to stand up all those different resources um and then lastly it outputs uh all that to the state file so if you haven't seen terraform it's very simple simple uh Hashi Corp and their wisdom decided to create their own configuration language versus using yo or Json but there's some benefits to it it's not a you know it's not a full programming language it's more of a specification um but you actually can write some logical operators in it um to

make it a little more flexible but in this example very simple piece of terraform but this is creating an ec2 so all you need to write is 12 lines of code to create an ec2 in AWS so you don't have have to write hundreds of lines of code it's not it's not complex at all and you can run this terraform plan terraform apply and uh your ec2 is going to be set up the interesting thing is even though you define very few things in that ec2 uh terraform in the back end is defining all of these things so this is what a terraform plan looks like once you've run once you've run the plan so it's

defining all these different attributes that you didn't Define some are default some are null some are um you know maybe account specific things and it's populating all of them even though you didn't say what to do and here's kind of a zoomed in version and so you can see there's already some interesting things on a very basic example uh of terraform you can probably spot one which is get password data which is a way to actually get password data out of Windows ec2 instances um so even though we're not defining it all those things exist which makes you know you have to think about these things from a security perspective and this is part of the magic that what

of what terraform does is you don't have to Define everything it will handle a lot for you which is a good and a bad thing but it definitely simplifies things quite a bit and that last piece is the terraform State file so like I said when you want to manage something through terraform it's not just run the Run terraform once and then you ignore it for the rest of the existence of those resources you continuously use your plan files and your state to basically manage the life cycle of those resources so if you want to go create an ec2 you write the terraform you run terraform plan and apply it creates it when it's time to

tear that down you again use terraform to do an destroy it's going to go to that state file it's going to say what is out there in this state what am I destroying um and that's that's pretty impactful for security for a couple reasons um one is it has a map of your entire environment so if I just had your state file in enough time I could understand your entire Cloud environment which is pretty important if you're a red teamer or you're a malicious actor um understanding the entire environment based off of one file uh pretty pretty good um pretty good amount of information the other thing is it holds secrets so any secret that you deploy

through terraform which I wouldn't recommend you do use terraform to deploy Secrets but a lot of people still do it um and a lot of resources also give you Secrets like RDS the master password gets printed to the terraform State even if you don't set it because it has to have a master password to basically start um so it's an interesting file for that reason and here's an example of a AWS Secrets manager secret so I created a secret my secret value not not great um I run a terraform plan and apply and that secret ends up in the state file so if I have you know systems passwords if I have database passwords whatever it is

and I use ter form to deploy those values all that's going to end up in the state file um there's no real great way around that um and so if you're a red teamer these are great great um things to go after figure out where your state file is a lot of people use S3 as a backend um to hold that state file figure out if you're a blue teamer figure out what are the permissions on that S3 bucket is it public is it semi-public to your entire company um definitely figure out how that's managed because people spend millions of dollars on Secrets manage management tools and then they throw them all into Secrets manager uh sorry they throw them all

into the state file which becomes another Secrets manager um and I think this is I always say this I feel very bad for this guy because I've done this talk a bunch of times and called him out each time but this is a GitHub issue on the terraform repo from 2014 where someone's basically saying hey we have secrets in EST State file how do we how do we prevent that how do we handle it um so from 14 we're almost to 2024 so 10 years um this screenshot I took a couple months ago but this is a PM for Hashi cour being like yeah we're working on it we're aware of this issue we have no solution

for you so almost 10 years that this has been an issue and Hashi Corp has not done anything to really address it there's some like hacky ways that people try to get around this the big thing is not using terraform to deploy Secrets but as I said it's not possible to completely avoid that um and hash Corp doesn't have a good solution for you so B basically treat State files like you know um like the golden ticket to the rest of your environment every talk has to have one meme I'll give you this one so this is uh very sad but true and another another kind of aspect of infrastructures code security is in the aptec world we talk a lot about um

you know s bombs and all the libraries and packages that we use in our applications in the terraform infrastructure as code world it's the exact same thing um you have this is just a list of some of the providers that Hai Corp gives you so terraform is a very basic language on its own you can't do much with it unless you use a provider like the AWS provider or Azure or whatever it might be um those are what interface basically between the apis of your Cloud that you're using and terraform so those Define all those resources and then terraform takes those and reaches out to the cloud environment and makes those updates so uh all of

these are massive code bases um and you're going to be pulling in at least some of these probably five to 10 honestly in any environment so see I I didn't put any music on but someone over there put on some music so someone got them someone told them what they wanted to hear but uh yeah all these are massive code bases so actually this morning I checked um I pulled down the latest AWS provider and it's all written in go terraforms all go um and that's 1.8 million lines 1.8 million yeah 1.8 million lines of code that you're pulling in um this is the official Hashi Corp provider for AWS So in theory we trust it you know it is on

GitHub it does take open source pull request and we know how that's kind of gone at times um someone was telling me yesterday one of their devs got in trouble because they were approving Duo pushes for pull request approvals by tapping their Apple watch on their forehead because they got so many of them that's just the reality uh that we live in so don't trust the fact that there are poor request approvals on this that no malicious code will ever get you know added to this repo but when you're using terraform and you're using these providers you're trusting all that code on top of the terraform code you're trusting the provider code and there's a

lot of open- source providers that um that are not maintained by hashy Corp anyone can write one of these you can write it for whatever API you want and have terraform manage it there's a Domino's provider uh what were the other good ones I think a Tesla one um there's a lot of different providers out there so people write them to use terraform to manage the configuration so you're trusting a lot of code when you use these tools um terraform API so if you're using open source you don't have really an API uh exposed it's just a binary that runs in your Jenkins or whatever CI that you use but if you're using um something like terraform Enterprise

which is hosted internally or terraform cloud or um spacelift uh you know a third-party CI tool for terraform they all have apis that expose all these actions so it's one more kind of a tack surface we have to think about with infrastructure as code tools if your API is open to pull your state file out I can just use that to grab that state file get those Secrets pivot elsewhere if I can use the update plan file or update State file app ction in your API I can do a lot of damage basically um so it's one other area to think about when it comes to terraform is all the apis that can be exposed as

well another facet of this is logging so when terraform runs it has to assume a role usually you know it's assuming the ec2 role that you're running terraform on to do all the activities um it's going to do in the cloud if it's if it's like ec2 it's going to be an instance profile and for some reason they've they've sort of fixed this now but for some reason they decided that when it does that assume roll and if you have the TF log variable set high enough which is just an environmental variable uh it will dump out the full the full credential for that assume role if anyone's familiar with the cloud um you know if you have a

terraform role that has something like admin access and you have access to this STS credential you basically can assume that role from anywhere you want if there's no restrictions on it so all a dev has to do or malicious you know malicious actor has to do is set this variable to TF uh TF log to uh verbose or um or trace and then this gets dumped out you can then just use that to run whatever you want outside of terraform um and again I like Hashi Corps products I don't love their security so you can see in the middle they have the access key which is partially blanked out and now access keys are not considered

secret secret people say or AWS says don't expose the these but it's not a true secret with that you're not going to get anything um except for potentially identifying account what they didn't blank out is the secret access key in the session token I have no idea why they chose to do it this way because if you have access to cloud trail and you have access to this log you can look up both the access key and the secret access key the only thing that doesn't get logged is the session token so like I said I like Hashi cor products their security has a lot of room to improve um they are I think trying with with good feed back from

folks but there's still a lot to do um so yeah with all of that said I like this image hopefully it's big enough to read but the highlighted part says for competent persons only um which you have to think about why did that label get added to that tool because that's for testing you know electrical sockets and and uh lines um but the point with terraform is it's a really great tool there's a lot of opportunity for security integration with these types of tools but you do have to be aware of all the issues that are present or all the kind of threats and attack surface you have with them and now I'll kind of dive

into some of those so these are only a handful of of things that we discovered when we've worked on these projects like I said the the terraform code base is massive the provider code bases are massive there's so much more to dig into in this environment um so this is only some things that we have found in lockdown it's not everything for sure uh so I definitely suggest you know if you like digging into stuff figure out how you can use terraform to to you know gain more access so one of the first things I'll cover um is terraform is an infrastructure as code management tool so they make a differentiation between infrastructure as code and endpoint

management so people are familiar with like anible or Chef or puppet those are more focused on okay I have an ec2 how do I set it up how do I get my you know dependency set up all the packages I need they focus on that part and hashy Corp terraform is for the infrastructure part with that said they do give you ways to basically run scripts so you could use terraform to then run Chef on a server if you wanted to um but what issue does that present is you're now mixing scripting with your terraform so if you don't expect your developers to run scripts on your ec2s but they do have a way VIA terraform um you know you

just open up a hole to your environment so a pretty simple example is you set up an EC to you have terraform connect to it and then run a scripts post setup um in this case most people are probably familiar if they can read it but you know running netcat to get a reverse shell out of um out of production so if you're a developer and you don't have production access or some lockdown environment access because you know you do privilege access management where no one can get into production with uh without like a change ticket or break glass you can just use terraform to basically get a shell back out of your production environment or connect

from that production server into something else so it's just one technique that um you can use to basically run whatever code you want on the on the servers that you have in your environment um and it gets tricky when you combine tooling for terraform and tooling for code because it's two different concerns two different issues two different tooling sets really another example remote exec will run on your ec2 that you set up local exec runs or terraform runs uh like I said terraform has to assume a role to do anything terraform without access to your environment can't really do much um so if you have access to the box where terraform is running that means that you can do whatever you want

along with whatever terraform does so if it's on an ec2 that has um has a high privilege role you can run local exec to get that role or dump out the credentials or do whatever you really want to do it's another built-in another built-in functionality of terraform so in this example um we're running local exec we're curling the metadata endpoint if you're familiar with AWS the metadata endpoint is what ec2s use to basically get that temporary credential um dumping it out to a file and then getting it out of the environment curling out of the environment to use elsewhere so basically if you if you're a malicious actor you have access to a developer um

developer machine you write some terraform you push it up to the pipeline the pipeline runs it and you just dumped out a highly privileg Ro that you can use elsewhere uh so it's a pretty effective way to bypass a lot of controls to get access to things that would be much harder to do without more privilege access and sadly fishing still works getting people to click on links and download things still works so this is a pretty real um real Attack Vector if you're going after developers who have access to production pipelines so how do we prevent some of these things I think a lot of people are probably familiar with srep if you do

ABC um but if you're not sem grip is a open- source tool that it's semantic grip which basically means it builds on the pattern matching of GP to give you more uh flexibility more logic you can add metadata to it you can have variables in it but it's a really simple tool overall because if anyone's done ABC for a while you've struggled with check marks Sur veric code or uh hopefully not fortify but there's probably someone in the room who's had to deal with fortify on a daily basis um I'm sorry but you know we've had these heavy static analysis tools and they're just not a good fit for fast pipelines where people are trying to deploy every

you know every day every few hours so tools like sem grip are great because we're looking for very basic patterns for with this kind of uh issue we're not looking for complex multi file types of issues these are these are single variable single single provisioners we're looking for um so we don't need complex rules to prevent some of these things so if you introduce semrep into your environment if you have pipelines that run you know something like Terra grunt to do unit testing for your terraform and then you can add semrep as an additional layer um and we actually push some rules to the semrep registry for for these provisioners so if you just use their terraform rules you'll get

these prevented in your pipeline so you don't have to you know introduce a huge outside of the normal pipeline security solution to prevent a lot of these issues um that's the great thing about it there's a paid version but you can just use the open source version and get this uh for free so the great thing about terraform is it is a relatively simple language there's definitely complexities uh yeah there's definitely complexities when it comes to modules and how certain variables get hidden when you um you're doing references and things like that but there's so many easy solutions to to use with this type of language because it is a specification driven language versus a

you know Ruby or or python or Java where there's much more abstraction much more complication another thing terraform is great for is gathering data so like I said the state file is a huge source of information about your environment um definitely go after that if you're doing testing for clients or for your own company um but there's other ways uh the terraform can access your environment so you have to think about it anything that terraform can can um manageing your environment update create destroy it can also have access to to read so any secrets management Secrets any SSM parameters um any password data that that can be harvested that's all available through terraform um and there's some built-in

interesting functions uh that they give you that again they're not just pure infrastructure as code tools they're they're kind of hacks built into terraform to give you a an ability to do other things so there's not a really in-depth provider for uh HTTP web calls it's not there's no like curl for terraform but they do give you this HTTP data call and in terraform there's data resources and there's um manager resources manager resources are your ec2s your RDS the actual Cloud resources data is something that you reference it could be a static file it could be like a Json document for a role um or in this case we're actually calling we're calling the meditata instance to use as

a data reference um so again we can use a built-in technique to run this terraform have it dump out the STS rooll um this will get output output in the pipeline logs and you can know use that to get access to the environment so that's what this would look like again if you have admin access assigned to your terraform pipeline you're going to be giving someone admin access to it if they run this type of script so again the great thing about this is these are very simple things to solve for uh you don't need fortify or check marks or whatever you need a very simple solution you could get away with grip uh you could get away with a like you don't

need a lot if you use Powershell I don't know what you need but probably a switch of uh tools but you don't have to have a hugely complex uh pipeline or security tool to fix these issues you can just write basic sem grip for all of this the one thing I'll say is that sem grip the current policy set except for the ones that we've written they don't think about the malicious use cases they just think about the misconfiguration use cases so some of these you'll have to write yourself but again they're very simple so another built-in functionality um of terraform is something called external data um again they have all these weird little wrappers built into

terraform that you know this isn't meant for just setting up your ec2 this is for running scripts um you know in this case we're running a python script you can run bash you can run just inline scripts and there are all these kind of hidden features of terraform that can really bite you if you don't realize that they're out there and give people privilege access to your environment so in this case we're doing we're running external data which is again just running a script it's a data call but it's just running a script and so we're running a python um a python script in the query we're referencing a data call which is to a secret manager secret so

we're pulling in a secret manager secret and then passing that to the python and then that can be exfilled out of the environment so again anything that terraform has access to you can pull that out and then xfill that out of the environment and use it elsewhere so surip is great it's it's a really good tool for appsec and for um and for things like terraform but if you want to do compliances code if you want to do more in-depth Logic for uh for your infrastructure as code there's other solutions that give you a little more in-depth tooling um they give you more logic than those basic tools a couple that we've used are Hashi

Corp SEL which is a paid tool I'm not I'm not chilling for hash Corp um I usually insult them more than I than I promote them but they do have a tool that they created for this use case and then Opa Rego which is an open source tool from the open policy agent folks um Rego is a whole language it's it's kind of interesting and weird but uh you can use it for appsec stuff you can use it for IM policies pretty much anything that you can write test for you can use Rego to do validation on security um security rules so we've done a lot of work with Sentinel which is another homegrown language from hashicorp they just love

doing their own thing versus using you know all the tools that are already out there but it's still a pretty simple language you can Define variables you can you know Define functions so you can do everything you can really do with a normal language so in this case we have 16 lines of code that what we're doing is we're grabbing all the ec2 from um the plan file we're creating a list of allowed types of ec2s and we're just doing a filter on what is not in this allowed list so in 12 or 16 lines of code you basically have a way to prevent people from using certain ec2 sizes that's a really basic example that's not

hugely security impactful but the point is again what I like about these tools is you don't have to write thousands of lines of code to get this in your environment to prevent these things if you write one sem GP rule or one Sentinel rule that prevents S3 from being public you're probably going to prevent an eventual breach uh because everyone has an S3 bucket that's public at some point um so that's what's great about these tools is they're not complex this is a slightly more complex version but this is basically saying what role can terraform assume if you have a defined role you don't want it to go assume you know your devops Ro or

something like that or your your Brak glass role so again these are really simple rules so I touched on this at the beginning but after unknowns are an interesting Edge case with terraform because like I said there's certain values that aren't known until the plan is run you can't know what the AR value is for a resource uh if that resource doesn't exist but if you write a rule to say I want to use this KMS key um it has to be defined on my S3 bucket but that KMS key doesn't exist how do you write a rule to enforce something that doesn't exist so this is where you get into an edge case where these values become

after an unknown and that kind of code sample is from a plan file where all of these values go in the after an unknown block and if you write a sentinal rule or sem grip rule that looks for a basic match for something like you know kmsk key equals this or look for the presence of public being true if you don't have logic built into your rules you can bypass uh all your rules and this is an issue that we discovered and brought it to Hashi Corp and they don't really have a solution so we basically had to write code to explicitly validate when something is after unknown and not allow it so if you were an attacker and you

wanted to bypass these rules you have to force the values that you're trying to bypass to be after unknown that's not as hard as it sounds if you use something like operational uh like conditionals in your terraform you can make these after unknown so make it after unknown The Sentinel rule will pass you can make an S3 bucket public you can make you know something unencrypted you can do whatever you want so this is a pretty big issue when it comes to terraform because it's just a built-in functionality of how it works um so you have have to have those explicit checks for after unknowns so those are a lot of the issues that that we've seen in these

environments um and some of the safeguards that we've that we've also built out um but there to solve these issues you really have to have layers of Defense you can't just have one you know you can't just have semrep and call it done you have to think about how you build these pipelines how you use terraform how you use cloud overall to have a really good um program for for for defending against attacks with these pipelines so I mean some of the things are IM is of course kind of your first sign of Defense um patterns is a huge part code review obviously um but kind of the first one is the great thing about Cloud environments especially AWS

in my opinion IM is such a powerful tool for security issues because you can write very fine grain policies to say you know this principle can do this at this time with these conditions being met you can prevent a lot of these issues if you have a terraform role that can't be run outside of your VPC or your org you prevent someone from assuming that role if they do get access to the SS credential so build those guard rails um you know for how your IM IM rules can be used especially your privileged ones and always build your policies to be least privileged again that's really difficult to do it takes a lot of time

but it can be done um you just have to kind of do it incrementally and build out those policies so that you give least privilege to your pipelines and the big thing is monitoring changes if people are changing your terraform role or whatever pipeline role you have things if it's constantly happening things are probably going wrong or if you see a brand new uh you know set of policies being added something is probably going wrong um if you don't use eks in your environment and eks permissions get added then you know some someone's done something either maliciously or accidentally to get access to that environment another big part is patterns um I don't know if people in their

day-to-day if they don't do architecture they might not think about how to build patterns for how services are adopted but have patterns for how things like terraform are used what your network stack looks like what your application Stacks look like if you're adopting RDS what is the pattern of how you all are going to use it look like so you define you know the networking you define the guard rails um you define the IM permissions and then you can use things like Sor or semrep to basically uh enforce those those those rules when resources resources are provisioned and that leads to those Services being hardened out of the gate so again if you have rules that prevent you from having

a public RDS you're not going to have public rds's unless someone goes in and starts messing with your resources so it's really important to have those patterns documented have the guard rails and then turn that into infrastructure code rules and then I covered this quite a bit but it's there's no way to have enough appsec people or Cloud security people to review all of your infrastructur code uh you know deployments there's no we're always going to have more developers than security people they move much faster than we can possibly read all their code so you have to have automated code review in your pipelines to prevent these kind of things infrastructures code code has not been focused on as

much in that way uh I think people are getting a little more wise to it but people haven't focused on it a huge amount but um it's definitely an important thing to do and again monitoring you should monitor the IM policies for your pipelines you should monitor uh the resources that your pipelines um provision if you're only in Us East one and US West two and you start seeing stuff in in AP region in AWS you know something has gone wrong so you need to be monitoring the resources that these pipelines provision as well because the first thing that attackers are going to do is try to get out of an area that you're really monitoring

well so final thoughts uh despite all the things I say about Hashi Corp and terraform I'm actually a big fan of the tools I just think you have to kind of go into it with your eyes wide open of the security issues it's a great Target for red teams or malicious actors and if you're a blue teamer it's also a really big opportunity to um make a big difference in your Cloud security environment so definitely check it out um if you have any questions I'll be around today and also you can reach out uh glad to talk about it [Applause] thanks