Deploying IaC Securely, and the Risks of an Insecure Template

Let’s take a look at Infrastructure as Code (IaC) and how we can identify and fix misconfigurations in IaC templates.

The first thing we want to cover is our environment. For purposes of this blog post, we’re going to be leveraging a CloudFormation template (CFT) to deploy on to the Amazon Web Services (AWS) platform. Our CloudFormation template is (a) in YAML format, (b) a known insecure template, and (c) stored within GitHub. This CFT is the ‘cfngoat’ template, which is a template designed in a vulnerable manner and provides a learning and training opportunity to show how configuration issues can find their way into production cloud deployments. This CFT can be found here: https://github.com/bridgecrewio/cfngoat

Why should we use IaC?

IaC allows you to spin up infrastructure by simply running a script, provides configuration consistency, minimizes risk, and provides cost savings (just to name a few benefits). Given the ephemeral nature of cloud deployments, IaC templates can and do change. Scanning these IaC templates for misconfigurations can mitigate risk prior to any production deployments.

IaC allows your organization to use Continuous Integration and Continuous Deployment (CI/CD) techniques while minimizing the element of human errors after development.

You can also spin down environments when they’re not needed or in use. This will decommission the resources that your script created, so you won’t end up with “orphaned assets” that your team is afraid to remove. This provides a clean and organized cloud account.

As IaC becomes the de facto standard in cloud infrastructure deployments, it is critical to ensure that your templates remain secure and protected. We’re going to explore how to accomplish this leveraging Palo Alto Networks Prisma Cloud.

Let’s deploy a CFT!

We’re going to start off with our CFT and deploy our environment. Let’s go on the assumption that this CFT was provided to us by our internal teams based on their knowledge on how to build out a templatized environment. We’re going to upload the CFT to AWS to get our environment deployed. This, along with an S3 bucket, are common means to deploy CFT templates.

Once complete, we’re ready to deploy our app … or are we? Let’s take a look at some of the configuration details.

First, we take a look at one of our Security Groups. You’ll notice some major issues here. SSH is configured for a 0.0.0.0/0 source. There’s also an Any/Any rule for 0.0.0.0/0. Both can, and will, have disastrous consequences.

Now, let’s look at our S3 Bucket. This CFT created an S3 bucket with our data, open to the public. Now, there may be situations where we need a publicly accessible bucket, but those are few and far between. Typically, you will not want to leave a bucket open like this. There are more secure ways to distribute public content without making the bucket public.

There are many other issues with this CFT and we can spend an entire blog post reviewing them, but we want to focus on what an organization can do to prevent this situation from ever happening to begin with.

Focusing on IaC scanning best practices

Scanning IaC should be a part of any development process and these templates should be treated as ‘living code’. Regions change, IP schemes change, Amazon Machine Image IDs change. Writing and configuring a CFT is not a one-and-done activity.

Leveraging Code Security in Palo Alto Networks Prisma Cloud, I add my GitHub repo to scan my code. Most major code repositories are supported in the Cloud Workload Protection (CWP) / Cloud Security Posture Management (CSPM) market, so while I’m using GitHub, you may use alternatives. In this case, I point to my CFT repo and initiate a scan of the YAML template.

Upon completion of the scan, 55 separate issues are identified. These are 55 issues we did not know about when we initially deployed. In the next three screenshots below, you’ll see a few examples of security / configuration issues discovered.

Issue One: Access Keys stored in the CFT. This is a very risky, ill-advised way to store credentials. In this particular GitHub repository, this CFT is public. Anyone can view these access keys and now have a potential attack vector.

Issue Two: You’ll note the Security Group (SG) configuration notes SSH (Port 22) with a ‘To’ and ‘From’ indicating 0.0.0.0/0. This CIDR notation indicates any and all traffic.

Issue Three: Our Elastic Block Storage (EBS) volume is not encrypted. Now, there may be situations where you would not encrypt a volume (such as the OS volume), data drives should be encrypted as part of standard configuration.

The alerts discovered were unknown to us prior to our initial deployment, and this shows how critical it is for organizations to incorporate security into their IaC program.

Now, many CWP / CSPM technologies do offer remediation options. You’ll note the “fix” button in the upper right of these alerts, and this may be a good option for that initial remediation. It is still recommended to review each of these as opposed to a blanket fix.

In this case, our policy dictates that Elastic Block Storage (EBS) shall be encrypted. In the original CFT, this configuration was not in place. We took the action to remediate this configuration issue and received confirmation from the tool in use, Prisma Cloud.

Upon completing the ‘fix’, we receive notification of the fix and to which policy it is matching to.

As discussed, there are many advantages to IaC. Speed, simplicity, consistency, risk mitigation, and the list goes on. But creation of an IaC template is not a one-and-done. Scanning provides continuous governance to enforce policies in code (such as CIS, HIPAA, PCI, etc.), ensures a less reactive approach when issues arrive and enables DevOps procedures to be applied to the templates.

Comments are closed.