This article goes over the process of creating an AWS Sandbox account. The primary goal for the sandbox is to allow developers to play around in an AWS account while creating safeguards to ensure they do not create a security hole in the AWS account through a misconfiguration.
This is primarily done using IAM policies and security groups. The design is available as a Terraform module in this GitHub repo.
Definition
The definition for an AWS sandbox as pertains to this article is important to understand the design considerations made for the sandbox.
For creating the definition of the sandbox, first we’ll need to define the roles of the people who would be using it. The sandbox is intended to have two roles – an Owner and a SandboxUser.
The Owner will manage the creation of the sandbox and set up access to it for the SandboxUser.
The SandboxUser would making use of the AWS sandbox to experiment with AWS services and create prototypes.
The definition for this AWS sandbox given the above roles is as follows –
- The SandboxUser must have full administrative privileges in the sandbox to enable free experimentation.
- All inbound network access from the internet must be restricted to a trusted IP.
- All S3 buckets must be restricted from public access.
- The sandbox account must not allow weak passwords for IAM users.
- Any of the above configuration items must not be modifiable by the SandboxUser.
Design
The sandbox design consists of EC2, S3, and IAM baseline configurations that allow us to achieve the goals of the definition mentioned above.
The sandbox has two primary IAM users, one for the Admin and one for the SandboxUser. Both have full administrative privileges but the SandboxUser has an additional permissions boundary that restricts certain actions that would violate the definition.
EC2 Configuration
The EC2 configuration is essentially a VPC and a security group that allows inbound access from the VPC as well as a trusted IP that is configured by the Admin. This allows the user to access EC2 instances, Lambda functions, and other services that make use of security groups from the trusted IP.
S3 and Password Policy Configuration
The S3 configuration makes use of the excellent S3 Block Public Access feature to block any public buckets or bucket objects from being created.
The account is also set up with a strong password policy.
SandboxUser Permissions Boundary
Now, for the juicy meat that is the IAM permissions boundary for the SandboxUser. The functions blocked by this permissions boundary are as follows –
- Modifications of any rules in any security group – Allows easy restriction of any wide-open security groups or otherwise insecure security groups being created while allowing SandboxUsers to connect from the trusted IP as well as connect to anything within the VPC.
- Modifying the AWS account’s password policy – Enables enforcement of a strong password policy for all IAM users.
- Modifying S3 block public access settings – Restricts the creation of any public S3 buckets/objects.
- Usage of any Elasticsearch API functions – This is because it is currently not possible in any form to restrict a user from creating a public AWS Elasticsearch instance (AWS please).
- Removing the permissions boundary of any IAM user/role – Restricts removal of the SandboxUser permissions boundary, or permissions boundary of any user or role created by the SandboxUser.
- Modifying the Owner or its policy – Restricts tampering with the Owner IAM user to prevent issues with the administration of the sandbox account.
- Modifying the SandboxUser, its policy, or its permissions boundary – Restricts any privilege escalation attempts by modifying the SandboxUser’s own policy or permissions boundary.
- Creating additional IAM users/roles unless they have the same permissions boundary as the SandboxUser -Restricts privilege escalation by creation of new IAM users/roles with administrator privileges as they would then be subject to the same permissions boundary as the SandboxUser. Big thanks to this AWS blog post for the particular technique used here!
That wraps up the design portion for the sandbox and hopefully was a good explanation of how the sandbox was designed according to the aforementioned definition.
Future Improvements
Although the sandbox design does encompass all the requirements set forth in the definition, there is some scope for improvements that would allow easier usage of the sandbox for organizations which have different requirements.
The IAM users currently used for the Owner and SandboxUser could easily be replaced by AWS roles for people who prefer granting access using either a SSO provider or through another AWS account.
The IAM users created by the SandboxUser could have the ConsoleLogin functionality restricted, but it would require creation of a second permissions boundary that should be updated in the permissions boundary of the SandboxUser, so that it can be restricted for newly created IAM users but the SandboxUser themselves can still use the AWS console.
There are numerous AWS services so this is by no means a comprehensive sandbox and there could certainly be some services that would allow escaping it, per the definition stated above. However, the goal here was to prevent usage of common AWS services insecurely and protect against the risks of misconfiguration posed by these services.
Please let me know if you have any feedback/suggestions for improvement!