The great thing about tech is that useful innovations are always arriving. While Infrastructure as Code (IaC) isn’t brand new, it still feels shiny and its popularity is really taking off. For newcomers to the concept, here’s a quick summary:
IaC is the process of managing and provisioning infrastructure through machine-readable definition files, rather than physical hardware configurations or GUI-based config tools. The definitions may be maintained in a version control system such as Git. The approach used may be declarative (WHAT) or imperative (HOW). The declarative approach defines the desired state and the system executes what needs to happen to achieve that desired state. The Imperative approach defines specific commands that need to be executed in the appropriate order to achieve the desired state. The recent focus in IaC tools is on the declarative side (e.g., AWS CDK, Terraform).
One of the coolest aspects of IaC is that it brings a whole new dimension to what developers can achieve. It’s a powerful technology that offers more flexibility and independence to developers and cloud platform engineers.
"Technology alone is not enough." - Steve Jobs
And with great power, comes great responsibility. Just like source code, IaC can contain bad actors in the form of bugs and vulnerabilities. These can wreak havoc on your infrastructure and your organization’s reputation. And if you believe that the cloud provider is handling security for you - think again!
A concept called the Shared Responsibility Model comes into play here. Security is a shared responsibility between the cloud provider - such as Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP) - and the customer. In this 'shared model', the cloud provider is responsible for 'security OF the cloud,'. This means the cloud providers are responsible for securing the traditional compute services such as physical hosts, networking and virtualization.
Customers are responsible for 'security IN the cloud' and that means platform and resource configuration since that’s under your direct control. When you spin up cloud infrastructures, you're directly controlling the operating environment - this is true whether your instances are server-based or serverless.
Not all cloud developers are aware of this and/or comprehend the significance. One small mistake can expose a lot! The good news is that IaC is just code and at SonarSource, we know a thing or two about helping folks write clean code! 🤠 . This includes the popular languages and tools you’re using to configure and orchestrate your cloud infrastructures.
Below are a couple of issue examples caught by our IaC specific rules:
Scope permission vulnerability in Azure with a secondary location
Authentication vulnerability in AWS
We know that folks don’t always deploy with a single cloud provider so we have rule coverage for AWS, Azure and Google platforms. We’re just getting started in the IaC/Cloud-Native space and we’re already bringing lots of value with the dozens of rules we’ve already added.
Please visit Sonarpedia to see our rules for CloudFormation and Terraform. Or better yet, try them out yourself in SonarQube or SonarCloud. Please visit our Community to give us feedback and to grab the latest product news.
Thanks for reading and happy, clean IaC coding!