Just a reminder that Terraform is insecure by design and if you even THINK about using it to execute CI/CD deployments not built into the cloud (Jenkins, on-prem CI/CD, etc...), then you're a DOUBLE fool. God i hate my infra team sometimes...

  • 3
    🚩Insecure how?
  • 2
    Just commenting here so I get to know the reason why terraform is insecure
  • 0
  • 1
    [comment subscription]
  • 0
    Tactical dot
  • 0
  • 0
  • 6
    Tl;dr: the way IAM is enforced on terraform makes the roles extremely overpowered if they were to get compromised.

    Alright this got a lot more traction than i thought so here goes:

    Any good security advisor for AWS will say "please use cloudformation, dont use terraform". Why is that? The answer lies within how IAM roles and the IaC work together. Lets say you have a given cloudformation template; you only need the access to actually build the template and manage the resource state through cloudformation. There's an IAM role specifically for each cloudformation ability. You can have a role with only the ability to spin up and down a given cloudformation template, and nothing else.

    With Terraform, instead of just needing the ability to run the template, you need an Advanced user with the ability to create EC2s, create Lambda functions, etc... (continued)
  • 5
    Basically any resource you want to create with terraform, the IAM role running the Terraform code needs access to those resources to create and delete a given resource. This gets you an EXTREMELY privilleged account when you start factoring in best practices about VPCs, IGWs, Secret Management, etc... You have one IAM role that would control access to ALL of those things.

    So how does this play into CI/CD? I'm glad i asked myself! The way that you would traditionally do CI/CD is you would have a code repository with application code, which is then deployed, compiled, and ran on a machine automatically with SSH. This can be secure when done right and the principle of least privillege is followed.

  • 5
    In AWS, you're not pulling from github and throwing data to an EC2 insrance (at least you shouldnt be), you're writing IaC and storing that, as well as application code, in CodeCommit, then using codedeploy to deploy to codebuild, which would build your cloudformation template, and then codedeploy will push your application code to your instances created by cloudformation.

    This is a fairly complicated process, unless you have AWS experience. For people retrofitting for the cloud, what they opt for is a Terraform yaml stored in githhub that is invoked by a jenkins pipeline on a local machine. Of course you can do terraform the "right way", but you still end up with an Advanced privillege user with the ability to make changes to a given resource. Seriously; check the docs for amazon's how-to on CI/CD with Terraform. They're only deploying services for EC2s, but people REALLY want to create EC2s with Terraform, and thats when the big problems start.
  • 2
    op actually delivered
  • 0
    @sudo-woodo i aim to please.
  • 1
    Well, reading this, it is my professional opinion that the biggest vulnerability in this story is not terraform in se, but the codebase containing the infra tf files is insecure.

    Never, ever, ever, EVER would a good SA in their right mind use an offsite git repo (like github) to manage the infrastructure. For that you need to have a small local infra with a local git repo in a secure environment, behind your company's firewall and ids/ips, set up everything so it works with just pki. (The bomb is ssh keys issued with certificate validation signed off by your own CA) , ensure your sensitive credentials are locked away in a vault, use hashicorps 'sensitive' input tags and then ??? Profit!
  • 0
    @NeatNerdPrime wat

    That is a security risk but thats a risk with all IaC

    Its the way IAM is implemented in Terraform

    Did you read my TL;DR?
  • 1
    While I'm not disagreeing, do take what AWS say with a pinch of salt - they're always going to push their own products and being internal for a single cloud provider, they'll be able to take advantage of some specific features.

    Plus, nothing stopping you from breaking up your IaC if you're concerned with a single over-priviledged user/role.
  • 0
    @bnjns agreed, a service role per resource is good, but it's definitely by no means ideal. Terraform is just not as good when it comes to security as cloudformation.
Add Comment