AWS Security Blog

Writing IAM Policies: How to Grant Access to an Amazon S3 Bucket

In this post, we’ll address a common question about how to write an AWS Identity and Access Management (IAM) policy to grant read-write access to an Amazon S3 bucket.  Doing so helps you control who can access your data stored in Amazon S3.

You can grant either programmatic access or AWS Management Console access to Amazon S3 resources. For example, you might grant programmatic access to an application that gathers data from a website and then reads and writes the data to an Amazon S3 bucket. With console access, users who interact with Amazon S3 to download and upload files can use a web-based GUI instead of constructing API calls. Let’s walk through two different policies: one that grants programmatic access and another that grants console access.

Policy for Programmatic Access

The following sample IAM policy grants programmatic read-write access to the test bucket:

Sample 1: Programmatic read and write permissions

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::test"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::test/*"]
    }
  ]
}

The policy is separated into two parts because the ListBucket action requires permissions on the bucket while the other actions require permissions on the objects in the bucket. You must use two different Amazon Resource Names (ARNs) to specify bucket-level and object-level permissions. The first Resource element specifies arn:aws:s3:::test for the ListBucket action so that applications can list all objects in the test bucket. The second Resource element specifies arn:aws:s3:::test/* for the GetObject, PutObject, and DeletObject actions so that applications can read, write, and delete any objects in the test bucket.

We did not combine the two ARNs by using a wildcard, such as arn:aws:s3:::test*. Even though this ARN would grant permissions for all actions in a single statement, it is broader and grants access to any bucket and objects in that bucket that begin with test, like test-bucket or testing.

Policy for Console Access

For console access, we’ll need to make an addition to the previous policy. The console requires permission to list all buckets in the account. To list all buckets, users require the GetBucketLocation and ListAllMyBuckets actions for all resources in Amazon S3, as shown in the following sample:

 Sample 2: Enable AWS Management Console access to an Amazon S3 bucket

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListAllMyBuckets"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::test"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::test/*"]
    }
  ]
}

With the additional statement, users can view the test bucket by using the console. Without those permissions, access is denied. The console lists all buckets in the account, but users cannot view the contents of any other bucket. The read-write permissions are specified only for the test bucket, just like in the previous policy. If a user tries to view another bucket, access is denied.

Leave a comment if you have any feedback or a specific scenario that you want us to walk through.

For more information about IAM policies and Amazon S3, see the following resources:

-Jim

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.