Building Developer Sandboxes in AWS

Before doing anything: have “The Talk” about security

Sandboxes work best if you grant your users wide-ranging privileges. However, this means that their user credentials are valuable commodities: a way to spin up machines for cryptocurrency mining, or worse. Not only can you end up with a large bill, you might find yourself liable if your account is used to serve illegal content.

  • Use strong passwords and multi-factor authentication.
  • Never save access credentials in source code.
  • Never send long-lived or high-permission credentials to a browser, phone, or other uncontrolled client.
  • Don’t expose servers to the open Internet; limit security group ingress to connections from your corporate network.

Create a sandbox account — perhaps many

For AWS, the account is the atomic unit of permissions management: permissions granted in one account don’t affect resources in another account. For this reason, many organizations use different accounts for different tiers of their deployment: dev, qa, prod, and so on. A sandbox is simply another tier, one with fewer access controls than even the “development” account. So it should be its own account.

Prevent changes to the organization access role

When you create a new account in the organization, or when an existing account accepts your invitation to join the organization, AWS creates an admin role in that account, by default named OrganizationAccountAccessRole. This role grants the AdministratorAccess policy, and allows an administrator or other authorized user in the master account to manage the child account.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtectOrgAccess",
"Effect": "Deny",
"Action": [
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:UpdateRole"
],
"Resource": [
"arn:aws:iam::*:role/OrganizationAccountAccessRole"
]
}
]
}

Limit the types of instances that can be created

Do your developers need to work on instances with 4 TB of RAM? If not, you probably don’t want them firing up an x1e.32xlarge, which will cost you $26.688 per hour to run. Indeed, for most sandboxy tasks an m5.large, with 2 virtual CPUs and 8GB of RAM is more than enough, at a cost of $0.10 per hour.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireMicroInstanceType",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotLike": {
"ec2:InstanceType": [
"t2.*",
"t3.*",
"m5.large",
"m5d.large"
]
}
}
}
]
}

Limit the regions where resources can be created

There may be some cases where your developers need to create resources in distant regions: perhaps they’re evaluating the latency of cross-region access. But otherwise, it makes sense to limit them to your “home” region(s): not only will they experience lower latency in their work, you won’t have to hunt all over the AWS cloud to find “forgotten” resources.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictRegion",
"Effect": "Deny",
"Action": "*",
"Resource": [
"*"
],
"Condition": {
"StringNotEqualsIfExists": {
"aws:RequestedRegion": [
"us-east-1",
"us-east-2"
]
}
}
}
]
}

Pay attention to billing

Amazon makes it easy to figure out how much you’re spending, in near-real-time. While you can get detailed billing reports, it’s best to start with Cost Explorer, a free tool that gives you a graphical display of current and historical costs, grouped and filtered along several dimensions. Two of the useful dimensions are Linked Account, which shows you whether your sandboxes are using excessive resources, and Region, which shows you whether resources are running in places that you don’t expect. One of my “canned” reports is below: the month-to-date charges for our sandbox accounts, grouped by service. If you look at this first thing in the morning, you can catch most charges before they become excessive.

Set up a naming/tagging conventions, with an auto-kill Lambda for resources that don’t follow them

This is controversial, so I’m leaving it for last, but I think it’s an important feature. Even with the best of intentions, developers create resources and forget about them. Without at least a naming convention, you’ll be faced with a list of instances and have no idea who to talk to.

Wrapping up: this post is about enabling, not securing

As I was re-reading this post, I became concerned that it might be interpreted as an intro to securing your AWS account. It’s not.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chariot Solutions

Chariot Solutions

Chariot Solutions is a top IT consulting firm specializing in software and mobile development, and development in the cloud. Visit us at chariotsolutions.com.