Keep your AWS environments separate with IAM users and groups.

If you’ve ever fretted about your staging environment having access to your production S3 buckets and have considered or set up multiple Amazon accounts to keep this isolation, then Amazon’s IAM service is for you! This service lets you set up individual users and groups who have restricted access to your AWS services and data. We’ll set up some test users and groups with permissions to manage specific S3 buckets to show how this works.

Start with creating your users from the IAM -> Users page. You can create multiple users at once and each user will be given their own Access Key and Secret Key. These are the keys you use in your application.

Next create groups for the appropriate environments, apply permissions to those groups, and associate the users. From the IAM -> Groups page, get started via “Create Group” and set the group’s name. On the next screen, choose the Policy Generator:

From here choose which service and what permissions to apply to which ARN (Amazon Resource Name. For S3 it will look like arn:aws:s3:::<bucket_name>/<key_name>). You can add any number of statements setting permissions across all AWS services.

Once you’re done the system will ask you to confirm your choices. You will see a Policy Document that looks something like this:

{
  "Statement": [
    {
      "Sid": "[unique statement ID]",
      "Action": [
        "s3:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::bucket-staging/*"
      ]
    }
  ]
}

All permission systems across AWS use these policy documents now so if you are spending a lot of time with AWS it’s important to be familiar with the syntax (official docs). The final step is to associate the users with the groups, which can be done through either the Users or Groups pages. In the Details view you’ll see a warning that the Group has no Users or the User is not associated with any Group. Use the tools there to hook up things as necessary.

You’re now set! One AWS account, multiple environments, and each properly isolated from each other.

Learn more about IAM in the official documentation

Photo of Jason Roelofs

Jason is a senior developer who has worked in the front-end, back-end, and everything in between. He has a deep understanding of all things code and can craft solutions for any problem. Jason leads development of our hosted CMS, Harmony.

Comments

  1. November 02, 2012 at 14:53 PM

    I just used this to setup buckets for an app using different buckets per-environment for file uploads.

    One change I had to make was to have the policy have both:

    Resource [
    “arn:aws:s3:::bucket-staging”,
    “arn:aws:s3:::bucket-staging/*”
    ]

    That way the user can view and modify the bucket contents.

  2. desertratmatt@gmail.com
    Matt
    July 09, 2013 at 21:57 PM

    That works great for data storage, but what about preventing a developer from accidentally stopping a production EC2 instances?

  3. July 10, 2013 at 14:09 PM

    @Matt Great timing on this question. Amazon just released much finer grained permissions for EC2 and RDS and while I haven’t looked into it much yet, this should support exactly these kind of permissions.

    http://aws.amazon.com/about-aws/whats-new/2013/07/08/announcing-resource-permissions-for-amazon-ec2-and-amazon-rds/

    http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html

  4. September 25, 2013 at 13:56 PM

    Great work boys.  I just implemented it and it works great!