An Introduction to Secure Infrastructure as Code (IaC) Using Terraform | SUSE Communities

An Introduction to Secure Infrastructure as Code (IaC) Using Terraform


A hot topic these days is Infrastructure as Code, or IaC, and how to use tools like Terraform to deploy IaC. There are tremendous benefits for following Infrastructure as Code principles, one of which is security, or Security as Code.

What is Infrastructure as Code (IaC)?

Infrastructure as Code enables modern infrastructures such as cloud computing to be expressed in simple, human-readable files. The files can be in various yaml, json or other formats and be readable by IaC tools such as Terraform from Hashicorp.

The virtualization of infrastructure by public cloud providers and on-premises tools has enabled such ‘infrastructures’ to be expressed, or declared, by IaC tools, whereas in the past there were just too many permutations of resources and their configurations to be able to simply represent them.

The word ‘Code’ in IaC means the configuration files which declare the desired state of the infrastructure. The implication is that these files should follow the same workflow as any code such as application code, requiring a code repository that tracks all versions of it and enforces code management and testing procedures. The difference between this ‘code’ and previously used ‘scripts’ that IT administrators used to deploy infrastructure is that scripts were typically ad hoc configuration instructions that quickly got out of date, were lost, or did not ‘declare’ the desired state of the infrastructure in simple, human-readable form.

What are the Benefits of IaC?

Companies that require speed, scalability, and security for running rapid application deployment pipelines on modern cloud-based infrastructures can reap tremendous benefits from IaC. These include:

●  Speed. New resources such as Kubernetes clusters can be deployed in minutes or updated in seconds to add nodes, change configurations, or be removed.

 Consistency. By capturing the deployment and configuration details in ‘code,’ consistent deployments are ensured. Misconfigurations, ‘fat-finger’ mistakes, and other potentially damaging errors can be avoided.

 Scalability. Resources such as clusters, nodes, networks and storage can be scaled easily and quickly.

●  Costs. Resource utilization is more easily optimized through scalability, and people costs for managing deployments and investigating misconfigurations are reduced.

●  Security. By ensuring consistent deployment of infrastructure, security configurations can be enforced and are immutable. This reduces the chances that access controls are inadvertently left wide open or other backdoors or vulnerabilities introduced.

However, how can these configurations be continuously monitored once deployed into a production environment?

Secure Infrastructure As Code (SIaC) and Security As Code

Secure infrastructure as code (SIaC) refers to the ability to deploy new infrastructure that is ‘secure by default.’ This requires that appropriate security configurations in the hosts, orchestration platforms, and other supporting infrastructure be applied during the creation of the infrastructure. Security as Code refers to the ability to declare both static infrastructure configurations as well as run-time security policies for specific applications or other dynamic objects in the production environment which can be constantly changing, updating, scaling, or being removed.

The automation tool Terraform from Hashicorp provides one way to automate IaC and SIaC.

Terraform for Infrastructure as Code
What is Terraform and why is it important?

From Hashicorp’s Terraform Site:
“Terraform allows infrastructure to be expressed as code in a simple, human readable language called HCL (HashiCorp Configuration Language). It reads configuration files and provides an execution plan of changes, which can be reviewed for safety and then applied and provisioned.”

Terraform enables DevOps teams to apply and manage changes to hundreds of cloud providers to reach the desired state of the configuration. These include public cloud providers such as AWS, Azure, Google, IBM Cloud as well as platforms like Kubernetes and VMWare.

By using a tool like Terraform, new infrastructure such as Kubernetes clusters can be deployed quickly and securely, with appropriate configurations for locking down the hosts, networks, and orchestration platform.

For example, this simple example deploys a three compute instances of type ‘f1-micro’ with debian on GKE:

Running this IaC deployment is as simple as:

●  $ terraform init

●  $ terraform plan

●  $ terraform apply

And removing it is as simple as ‘$ terraform destroy’.

Of course, a production deployment would require many more parameters including initial configuration of the orchestration environment according to security best practices.

Security as Code for Protecting Kubernetes

Once the Kubernetes infrastructure is deployed securely, the next challenge is to enforce those security configurations and protect application workloads which run on it. In order to do this, we’ll need to deploy and configure the NeuVector Container Security Platform.

There are many tools to automate this deployment and configuration, including NeuVector Helm Charts, Operators, and Configmaps. Again, Terraform can work with these to automate the deployment of NeuVector and pre-configure security policies. This combination can ensure that a NeuVector security platform is deployed properly and configured to automatically begin auditing and securing the infrastructure.


Once NeuVector is deployed and configured it can be used to build security into the application pipeline so that application security policies are enforced. These policies can declare the allowed behavior of every new or updated workload and can be automatically deployed to production before the application starts to run. Kubernetes provides a powerful mechanism for this Security As Code called Custom Resource definitions (CRDs).

Below is an example of a ‘security as code’ yaml snippet in the NeuVector CRD format for declaring the allowed network, process, and file behavior of a node.js application.

The example above describes the ingress and egress connections allowed for the node.js application, including protocols as well as allowed processes in the running containers. This code, together with all other code for each application deployed, can be managed in a typical gitops automation workflow. In addition, OPA can be used, which is one of the security policy frameworks which integrates with Kubernetes. NeuVector’s CRD security policies can be a natural extension of OPA’s Kubernetes Gatekeeper.

How to Use Terraform to Deploy Secure Infrastructure as Code

In our next blog post, we’ll provide you with specific examples of deploying a secure Kubernetes cluster using Terraform. Then we’ll cover deploying and configuring NeuVector and sample applications securely using Terraform. Stay tuned for a downloadable guide … but in the meantime you can check out this webinar which includes the demos.

Read Part 2 of this blog.

Avatar photo
Glen Kosaka Glen is head of product security at SUSE. Glen has more than 20 years of experience in enterprise security, marketing SaaS and infrastructure software. He has held executive management positions at NeuVector, Trend Micro, Provilla, Reactivity, Resonate, Quantum and Rignite.