Over the years, Infrastructure as Code (IaC) has become increasingly popular over the last five years. Many organizations have seen the benefits to provide capabilities to rapidly provision and deploy cloud environments whilst having it as code.

Examples of IaC technologies tools are Terraform, AWS Cloud Formation templates, Azure Resource Manager templates, Chef, Puppet, Red Hat Ansible, Helm Charts, Kubernetes YML files, and OpenFaaS YML.

I have found that many companies mainly use AWS and Azure and Terraform. Moreover, companies who are trying to become cloud agnostic tend to lean towards a multi-cloud tool like Terraform.

as Code Security Insights Feb 2021

I have found that the best solution for IAC depends on your projects needs. If you have signed up for a five year plan with AWS and decide to build and grow on there, I would highly recommend to use AWS CloudFormation as you can do more with an in-house tool rather than use a third party one which maybe more expensive down the road.

What are the Benefits of IaC?

So why have companies been flocking and utilizing Iac over the past five years? I have seen that there are many benefits with having IaC inside your organization. Some of them are:

1. Faster speed and consistency: The goal of IaC is to make testing, building and deploying faster by eliminating any manual processes and eliminating slack within the set project. Even though some times you would need to invest some time in learning your IaC tool of choice, the code-based approach will make it easier to get more done in less time for your project. additionally, there is no need to wait on IT Admin (if you have one or two)to manually complete the task at hand before he can get to the next one. This also means that you and your team can iterate quickly and more often.

Consistency is another vital benefit of IaC. You don’t need to worry about tasks not being completed because it is a weekend or because your admin is focused on something else. You can just run the script yourself with all the assigned permissions and resources already set and tested. In addition, you can also implement changes globally while keeping the same version of the software, configuration. 

2. Efficient software development lifecycle: IaC shifts the power into the developer’s hands and reduces the burden on SysOps. As the infrastructure provisioning becomes more reliable and consistent, developers can start focusing on application development a lot more. Moreover, they can script once and use that code multiple times, thus, saving time and effort while keeping complete control over what they are creating.

3. Reduced management overhead: In a data center world there is a need to have admins govern and manage storage, networking, compute and other layers of hardware and middleware. However, with IaC, it eliminates the need for these multiple roles to track and troubleshoot everything. Those admins can now focus on identifying the next exciting technology they want to implement because IaC makes everything trackable, auditable and .

What are IaC Vulnerabilities?

There may be all these new benefits to having IaC. However, no tool or process is perfect. With new processes, software and code there comes some drawbacks that can impact the company at a critical level if it is not done properly.

There problems, I have found are:

1. Speed over security

Currently, deploying modern applications are becoming faster and more compact in an automated way using CICD tools and deploying on micro services. As a result, security so often takes a back seat to a speedy deployment, meaning configuration issues are not uncovered until after these applications have been deployed. This is where the notion of shifting left comes in for security. We need to start doing security testing from the start and not rely on pen testers at the end of the production cycle.

“By 2025, 70% of attacks against containers will be from known vulnerabilities and misconfigurations that could have been remediated.”

Yet, speed may be inherently risky when it comes to IaC if not done correctly. This is why we have automated testing and release gates which are put in place for other forms of code which can be used with IaC. This makes security practices more integrated into development and our release processes. The highest performers that can achieve this find little security vulnerabilities. Below shows a survey of those who are both finding and fixing configuration issues the fastest.

as Code Security Insights Feb 2021

2. Network Exposures

Insecure IaC configurations can expand the attack surface, which enables your surface to become exposed to a delivery of cyberattacks to a cloud environment. An example would be configuring open Security Groups, publicly accessible cloud storage services, public ssh access, and databases that are accessible from the internet. These are some examples of common IaC misconfigurations that increase the attack surface in your cloud environment. Below is a sample IaC snippet that highlights code with these issues.

Tip: You can perform static security analysis of IaC and eliminate risks early in the cloud deployment lifecycle. You can use tools like terragoat or Synk to detect and fix these issues early is highly cost-effective and reduces your residual risks.

3. Vulnerabilities

Today, IaC templates are used to provision compute and containerized instances by including base images stored in trusted registries. This presents an opportunity to detect and address any known vulnerabilities in such base images early and dramatically reduce the cost of remediation. The following examples illustrate the use of vulnerable AMI and Docker images.

Tip: Perform vulnerability assessment of images referred to within IaC files and detect vulnerabilities early in the development lifecycle.

4. Unauthorized Privilege Escalations

Today, IaC is used to provision full-stack cloud environments that may include Kubernetes, containers, and microservices. Developers often use privileged accounts to provision cloud apps and other layers, which introduces risk of privilege escalation. If this risk is combined with hard-coded secrets and network exposures, a serious breach path is exposed for attackers to use.

Tip: Ensure least privileges principles are enforced in IaC and detect privilege creeps in IaC.

5. Configuration Drifts

While developers might be following IaC best practices, an urgent situation may force an operations team to make a configuration change directly in the production environment. This behavior breaks the immutability of cloud infrastructure which is based on the premise that infrastructure is never modified after it is deployed. If something needs to be updated, fixed, or modified in any way, new infrastructure has to be provisioned through code. More importantly, the configuration change may introduce risk which results in the posture of the cloud drifting from the secure posture defined through IaC before the infrastructure was provisioned.

With the power of IaC comes the responsibility of managing security risks, which can be introduced if best practices are not followed. Insecure IaCs result in insecure cloud environments that could ultimately lead to compliance violations and data breaches in the cloud. According to the most recent Verizon Data Breach Investigation Report, cloud misconfigurations was one of the top reasons for incidents and breaches.

How do you test if your IAC is secure?

The only best way to monitor and test if your IaC is secure is by using a security tool to inspect, find and fix issues in your configuration files for Terraform or Kubernetes (including Helm) environments.

I will give a small tutorial of how to use Synk to inspect, find and fix issues in my Kubernetes code.

Getting started with Snyk Infrastructure as Code (IaC)


Ensure you have:

  1. A Snyk account (go to https://snyk.io/ and sign up – see Create a Snyk account for details).
  2. An existing Kubernetes or Terraform environment to work in.
  3. Integrated your Git repository as for other Snyk products – see Git repository (SCM integrations) for more details.

For more details, see:

Stage 1: Add projects

Import projects to test with Snyk, by choosing repositories for Snyk to test and monitor.

  1. Select Projects from Snyk.io.
  2. Select the tool to add the project from (for example GitHub):

  3. In Personal and Organization repositories, select the repositories to use.
  4. Click Add selected repositories to import the selected repositories into your projects.


  5. A progress bar appears: click View log to see import log results – for example:

    (you can scan both Kubernetes and Terraform files simultaneously, as in this example.

  6. Project import completes.

Stage 2: View configuration file issues

View results for configuration files in imported projects.

  1. Select Projects, then click on the imported project entry, to see information for scanned configuration files, including the number of high, medium and low severity issues found. For example:IaC_-_issues_list.png(Issues are sorted into project types: Helm, Kubernetes and Terraform.)
  2. Click on a project to see more information and details of the issues in a configuration file:IaC_-_select_config_file.png

If you encounter any errors during import, see the Importing projects information.

Stage 3: View and fix config files

Act on the recommendations produced by Snyk IaC.

  1. IaC results appear as direct issues in the relevant scanned configuration files. For example:

  2. Click on an issue to see the details for that issue, and specific recommendations from Snyk IaC. For example:

  3. Edit the configuration file to fix the issue identified, based on the recommendations, then commit the change.
  4. Snyk automatically rescans the changed file, and you can see the change reflected in the issue display.