Terraform and Compliance

[David Sachdev]

One of the issues we have found with Terraform scripts is that they can be complex, and while they are designed to help remove that complexity (and in theory make things repeatable, documented, and portable) there are also compliance and security concerns.  Unless you thoroughly understand what a terraform script is doing, you may violate your agency's security polices on things such as creating open gateways or the like.  How do you suggest getting a deep understanding of everything that the terraform script is doing while you are learning terraform and utilizing open source terraform scripts?

Thanks
David Sachdev

[Scott Winkler]

Security and compliance follow complexity. To be able to write effective security policies you first need to modularize your code so that each part serves a specific function, which requires less cognitive load to fully understand. The worst thing you can do is have a single massive codebase that deploys hundreds and hundreds of different resources. How are you supposed to govern that monstrosity? Half the times its a miracle if it applies with no errors. I am a fan of polyrepos and deploying large projects with multiple workspaces, rather than single workspaces. This allows each workspace to be more cohesive, and reduces the blast radius in case something goes wrong.

In chapter 13 of my book I discuss a few options. If you are using HashiCorp proprietary solutions like TFC/TFE, you have Sentinel. Its not great, but its alright. It allows you to write specific security policies you want to enforce on workspaces, and then not allow applys to go through if the policy fails. For example you could prevent someone from deploying 5000 EC2 instances, or creating a security group that is open to the world. If you are interested in Sentinel, I would recommend taking a look at the third generation policies located here: https://github.com/hashicorp/terraform-guides/tree/master/governance/third-generation.

Another possibility is OPA. I like this option better than Sentinel, because it isn't proprietary and actually the language is much superior compared to Sentinel. However, theres not as much documentation on this because not so many people are doing this.

I think many people "want" to be writing policy as code, but it almost always falls by the wayside. The best recommendation I can give you is to write as specific of policies as you are able. Don't try to solve everything at all once. And make sure you have an audit trail for who made what change on what date.

Finally, there are some 3rd party companies trying to solve this problem as well. One such that comes to mind is Lightlytics, although their solution only works for AWS.