WARNING! Infrastructure as Code+

There is a very scary trend beginning that, as a Security Professional, I think needs to be discussed. Infrastructure as Code is an amazing technology concept for allowing professionals to define "in Code" or definition files all the necessary configuration and resources needed to build and deploy infrastructure, typical among Cloud environments. This isn't the scary part. The scary part is who and how you create and manage your infrastructure as code source files.

Conclusion

Let's actually begin with my conclusion. In conclusion, putting responsibility of Infrastructure as Code in the hands of Developers is a very bad idea. Using tools that allow multiple general programming languages to communicate and provision directly against a Cloud Provider API is a bad idea in my opinion. My main reason for this is Security. The security of infrastructure should never be an after thought, an add-on, or buggy. Developers are really good at developing applications. Being a Full stack Engineer is hard enough, but expecting Developers to also be Security Professionals as much as say DevOps is a far stretch. Security should be left in the hands of professionals like DevSecOps where security and deep infrastructure knowledge is at the forefront of their skills and job description. Also, general programming languages are more buggy simply because they are bigger and offer a larger set of potential security holes. Furthermore, what happens when you have multiple different languages in your environment across teams to provision infrastructure--you lose consistency. This is what I term Infrastructure as Code+ (IaC+) to mean developers using general programming languages to provision infrastructure. We want IaC, not IaC+.

Who's doing it Right?

Before we give examples of this bad trend that's beginning in our industry, I'd like to shed some positivity on who's doing it right. One company, HashiCorp. HashiCorp is King when it comes to the full-lifecycle of application and infrastructure provisioning and deployment. HashiCorp's Terraform is the main software as part of their stack for provisioning infrastructure using Infrastructure as Code. They developed a very specific language to do just that called HCL or HashiCorp Configuration Language (which was developed in Go). Typically IaC is done in a Domain-specific Language (DSL) like YAML or JSON. Think JSON for ARM Templates or Azure DevOps use of HashiCorp's Packer which uses YAML. The advantage of HCL is that it's a true programming language and so has the advantage of sequence, selection, and iteration over traditional DSLs. But it's specialized to the task of provisioning infrastructure. Also there's a reason their is a command "terraform plan" to review changes before committing.

But it's not just about Terraform and HCL. You see, HashiCorp really cares about the entire story of infrastructure AND applications. So each product thinks about the whole picture. So when it comes to Security, HashiCorp has developed a whole other technology called Vault, very powerful software for managing certificates, secrets and keys among other things. So the provisioning story goes beyond some random cloud resource, but helps complete the bigger picture allowing Security professionals to think about secrets and passwords in their configurations. This tightly coupled stack together with a very specific language allows HashiCorp to "do it right!"

Update: As I'm writing this blog post, HashiCorp literally just published a few minutes ago that they are now enabling Python and TypeScript for their CDK for Terraform support in AWS. CDK is AWS's Cloud Development Kit, basically an API you can write against to provision resources in AWS but is open to allow any programming language to now work against this API. Pulumi is another example of what I'm afraid of. Of course I'm shaking my head now as I'm very afraid of this, but I can understand why they did it as the industry is headed this way. Stick with HCL people, or developers will take over your infrastructure leaving security as an after thought. At least though, Terraform CDK support for other languages simply translate back into Terraform code.

Why is it so Bad?

In my conclusion I wrote that putting responsibility of Infrastructure as Code in the hands of Developers is a very bad idea. Here's the deal. Software applications are buggy, that's normal. Applications have security vulnerabilities maybe from buffer-overflows, or some software exploit in how the code is written. In applications I get it, but for infrastructure, security holes like this is completely unacceptable. Equifax was brought down due to a faulty certificate on an Apache webserver on hardware first provisioned in the 80's. Infrastructure as Code has the really cool property of immutability, a sort of tear down and replace approach rather than finessing it with logic and one-off function calls. Furthermore, Infrastructure as Code needs to operate on the same Zero-Trust model that it is trying to provision. We don't want to be attacked from the inside similar to what happened to Twitter. And no one group should have so much control over the provisioned resources before, during or after. This is another reason why the tightly-coupled HashiCorp stack works so well.

Let's talk about Clojure and IaC+

Full disclosure: I believe Clojure is a contender for the best programming language in existence today (but maybe that's another blog post). But I needed a general programming language to pick on, I like Closure, and I recently watched one of the best IaC+ demos done in Clojure. Clojure is based on Lisp and because of this it has properties which other general programming languages have yet to catch up on. Namely it's based on the Functional Programming paradigm which limits assignment (all programming paradigms limit something and for Functional languages it's assignment). The way it works is the language itself uses data that is in turn the langauge itself. Data input to a Lisp-based language like Clojure just looks like more Clojure, and the language prevents you from doing a = b assignments. This immutability property lends itself well to IaC because IaC also has the property of immutability and thus solves some of the security issues I'm concerned about.

That being said, please watch how the small yet awesome team at StediInc performs a demo of how they developed and use cdk-clj in order to allow IaC+ using Clojure. I enjoyed the demo, but you have to admit, you didn't see much attention to Security, keys, secrets, etc in the demo. Developers typically want to quickly get the provisioning step out of the way so they can focus on their main job. I believe this is super risky for the infrastructure of any organization.

I'd loved to hear your thoughts on the matter, and do you see this as being a rising issues in our industry and a gold-mine for hackers?

Follow Me:

Azure: @azurejackson @YouTube

CyberSecurity: @ethicaljeans @YouTube