Timmy's First CloudFormation

Today we jump into Infrastructure as Code to set ourselves up for future labs.

Prerequisites

The Lesson

The past few labs ran a little long, as we covered fundamentals that were a bit hard to break up into smaller pieces. Don’t worry, I fully intend on making it up with this one.

I assume pretty much all of you have heard of Infrastructure as Code (IaC). This is one of the coolest supporting technologies to come out of cloud computing. Technically it’s existed since old-school virtualization days (hello Vagrant!) but cloud really took things to the next level.

IaC has some deep security advantages, concerns, and implications… nearly none of which we will talk about today.

The TL;DR of IaC is that we can write descriptions of what we want infrastructure to look like as templates. We feed these into an application like Terraform or a cloud service like CloudFormation, and the template is interpreted and used to build out the specified infrastructure and configurations.

When I teach cloud security in a classroom I tend to use a lot of IaC to shortcut operational stuff that would take too much class time. For SLAW we will use it for that, but also to allow you to tear things down between labs and reduce costs.

IaC is magic (until you need to debug it). These templates provide repeatable, consistent infrastructure builds that are practically self-documented. For example, I host the templates for various labs I manage for the Cloud Security Alliance, which are reused by thousands of students around the world every year. The instructors know with absolute certainty what a student environment will look like after they run the IaC.

For security purposes IaC is also deterministic. The templates are declarative and build exactly what’s specified (okay, sometimes they error out, but roll with it). Have to perform an incident response on an AWS account that’s been compromised? Use the IaC templates to see what’s different from what’s expected. Then use the same templates to rebuild the app in a safe account.

On the other hand, IaC is a royal PITA when some dev hard codes in credentials or vulnerabilities, and you get an episode of Battle Bots as your security automation fights the deployment automation. Not that that ever happens. Nope. Never seen it. Pinkie swear.

IaC isn’t perfect. The IaC tool takes templates and uses them to make a series of API calls to build the infrastructure. CloudFormation does this inside AWS as a managed service without requiring any other software configuration. Terraform from Hashicorp uses its own interpreter and is capable of supporting multiple cloud providers and a wide range of other software. For most of our labs we will use CloudFormation so you don’t need to install anything, and I can host the templates.

Today’s key points are:

  • Infrastructure as Code defines infrastructure as declarative templates.

  • CloudFormation is the IaC tool built into AWS.

  • IaC makes infrastructure repeatable, consistent, and portable. This is awesome for disaster response.

  • For security, IaC is deterministic, which gives us a roadmap to what the infrastructure should look like.

  • IaC mistakes can be made. They can be security mistakes. We’ll deal with that later.

The Lab

Our lab today is very simple. We will go into CloudFormation, run a template that I host, and build a Simple Notification Topic called “SecurityAlerts” in the us-west-2 region, and then again in the us-east-1 region. In future labs we’ll learn how to subscribe to these topics and get real-time alerts for security events in our account.

This lab has been updated to have you repeat the process in two regions. This is to show both the code portability, and to better prepare your environment for a future lab that needs both regions!

Here’s the template. The language is YAML but CloudFormation also supports JSON. I use both depending on whether it’s before or after Labor Day.

AWSTemplateFormatVersion: '2010-09-09'
Description: Template to create a SNS topic named SecurityAlerts
Resources:
  SecurityAlertsTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: SecurityAlerts

Yeah, it’s that easy. CloudFormation can do a lot more, and Terraform even more. There are also other options like CDK which we will, you guessed it, look at later.

The template is pretty readable. The Resources block includes all the things you want it to build. SecurityAlertsTopic is the reference name for what we are building. I could have called it “Timmy” and it would still work. This is so different resources can refer to each other when needed (e.g., build this security group in this network).

Type is what we are building, and Properties are configuration settings. SNS is simple, so all we are defining is the name of the topic. To get alerts we subscribe to a topic. Subscriptions can be for text messages, emails, or fancy internal things to create complex event-driven notification buses for applications.

Video Walkthrough

Step-by-Step

First, got to https://console.aws.amazon.com and sign in. Then double check and make sure you are in the us-west-2 Oregon region by clicking in the upper right:

Then click the Search box and find CloudFormation:

A stack is a collection of resources that CloudFormation deploys based on a template. This is the magic of IaC. Our stack today is as simple as it gets, but you can do all sorts of advanced things like embed stacks inside other stacks, use variables (called parameters), and even trigger other automations. Click Create Stack.

For this lab everyone will deploy a stack hosted in my account. One of the most common ways to host stacks is to keep them in Amazon S3 (Simple Storage Service). You could also design a stack right at that moment (CloudFormation would store it in S3), or you can upload a file from somewhere else.

Time for an important security point. Be very cautious about deploying stacks hosted in someone else's account. Anyone can host a hostile stack which could give them access to your account, deploy cryptominers, or nearly anything else. They can also change a stack, so one that was previously safe could become dangerous for deployments going forward; but stacks do not auto-update, so they can't change what you deployed after you deploy it.

I'll have you deploy stacks I host frequently as we work through these labs, but I strongly encourage you to get in the habit of reviewing them first. They are plain text files you can download or view in a browser.

Accept the default settings on this page and paste in https://cloudslaw.s3.us-west-2.amazonaws.com/sns.template as the URL for the template. Then click Next.

On the next page name it “SecurityAlerts” and then click Next.😀 

On the next screen scroll to the bottom and click Next. In future labs we will learn more about these options:

And… one more time! (Scroll down and click Submit this time, though). This starts deployment:

The next page is very important: it’s where you track the deployment and can see error messages. This early in, using my templates, the most common errors will be trying to deploy something that’s already been deployed (name conflicts), or deploying in the wrong region when a stack has region-specific resources such as machine images.

Stacks can take a while to deploy, but this one should go quickly. You can click the refresh button highlighted in the screenshot if you want to see what’s going on.

In the screenshot you can see all the events (in the red box) and the status. As you see, this entire stack is deployed: it’s marked on the left as CREATE_COMPLETE. Left side: overall stack status. Right side: current event status for all stack elements.

If you want to see the template, it’s always available (which is important once we get into incident response):

To finish up let’s go look at our SNS topic. Click the search box and find SNS (Simple Notification Service):

In SNS a topic is the resource you publish notifications to. Anything subscribed to the topic will get its notifications. Click ‘1’ to see our topic. We will use this later as the main mechanism to send security alerts to your email.

To finish up, let’s spin back over to CloudFormation and just look at the Delete button — DO NOT PRESS THE DELETE BUTTON. Okay, now raise your hand if you clicked it.

In most cases this will remove your stack. There’s also an Update option which… occasionally works. As you might imagine, both fail if something changed or some other dependency was created.

In other labs we will deploy what we need and use this to delete it when we are finished for the lab. It’s a great way to save costs.

Critical Second Lab Phase!

This part is easy, but incredibly important. Repeat the steps and deploy the CloudFormation Template into the us-east-1 (Virginia) region!!!

First, click in the upper-right corner and change the region:

Then… repeat the steps to deploy the stack in us-east-1. It only takes a minute and this sets us up for our future labs. We need the SNS in two regions to make it easier to link together services in the console to send alerts when services only work in us-east-1 (like billing alerts and some IAM alerts).

Just follow the steps again, it will take less than 2 minutes

Key Lab Points

  • CloudFormation is AWS’s built-in Infrastructure as Code tool.

  • Templates are declarative code used to built a stack of resources. For CloudFormation they are written in YAML or JSON. Our example is in YAML and creates a notification topic called SecurityAlerts.

  • Templates can be hosted in S3. If you use someone else’s, be careful it isn’t creating a security problem.

  • You can also update and delete stacks. We will use these a lot in our labs to create resources when we need them, and get rid of them between labs so we don’t pile up charges.

-Rich

Join the conversation

or to participate.