Building a cloud security training platform – Pt 2: Infrastructure As Code

This is a guest post by one of our trainers, Paul Schwarzenberger. Paul is running the fantastic Cloud Security and DevSecOps training course this June. He also has a blog where he talks about AWS, Cloud Security and DevSecOps. This is part of a series on how he’s built a platform to make things easier for those attending his training. Parts 1, 3 and 4 are also available. Thanks, Paul!

The Cloud Security and DevSecOps training course I’m delivering for 44CON in June includes AWS, Azure and GitHub accounts which the students use so they don’t need to create their own. As I described in my last blog post I also decided to build a training platform, so that students can connect to a virtual desktop in the cloud with all the software they need pre-installed.

That way they can come on to the course with any laptop or even tablet which supports the Amazon WorkSpaces client.

The next step after the proof of concept and design was to build it using as much automation as possible – to keep cost low, I wanted to easily destroy everything as soon as a course finished, and to rebuild just before starting the next one.

I’m also taking the opportunity to demonstrate good security practice, and I’ll use the training environment as an example to show students during the course.

An important security principle is segregation, so I decided to build the training environment in its own AWS account. But I didn’t want to have yet another monthly bill. So I used AWS Organizations to create the new account:

That way, billing for all my AWS accounts is consolidated, and I can also use Service Control Policies to enforce security policies on the new account.

The next step was to create the AWS Directory Service – this is an AWS managed Active Directory which I’ll use to manage user identities, for students to log on to their Amazon WorkSpaces virtual machines. I decided to use Terraform by Hashicorp, as it’s ideal for automating infrastructure as code:

Here’s an example of the code snippet used to create the AWS Directory service:

My terraform code included nearly all the required resources:

• VPC, DMZ and private subnets in multiple availability zones, subnet routes
• Network Address Translation (NAT) gateways and Internet gateway
• Key and key alias in AWS Key Management Service
• Virtual machine instance for Active Directory admin, security group and Elastic IP
• Amazon Route 53 domain name for AD Admin virtual machine Elastic IP
• Identity and Access Management (IAM) policy and role for AD admin virtual machine
• AWS System Manager templates for domain join and Windows feature setup
• Secrets in AWS Secret Manager for user passwords – more on this later

The one exception is Amazon Workspaces, as these are not supported by Terraform at the time of writing.

I typed “terraform apply” and about 30 minutes later the infrastructure was built in the new AWS account, and I could see all the resources in the portal. Here’s the AWS Directory service built from the code snippet above:

After some troubleshooting, I succeeded in automating the domain join of the AD Admin Windows Server 2016 virtual machine, using an AWS Systems Manager document template. I also created some automation templates to set up the Windows feature for Active Directory administration tools, and to install the AWS PowerShell Module, so I could use these later.

Then, I logged in to the AD admin virtual machine using Microsoft Remote Desktop with my domain admin credentials:

Opening Active Directory Users and Computers, I could see the AWS Directory domain.

All I needed now was some automation scripts to create users, and then build the Amazon Workspaces. I’ll cover these in my next post.