Restrictive S3 bucket permissions

If you are pointing a Simple FTP Service at an existing S3 bucket, you may not want to grant access to the whole bucket. You can scope the IAM policy of the access key you give DocEvent down to specific paths.

The scoped policy

This example allows object access only under the docevent1/ and docevent2/ prefixes of the bucket:

{
  "Statement": [
    {
      "Action": [
        "s3:GetObject*",
        "s3:PutObject*",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket/docevent1/*",
        "arn:aws:s3:::my-bucket/docevent2/*"
      ],
      "Effect": "Allow"
    },
    {
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket"
      ],
      "Effect": "Allow"
    }
  ]
}

Two things to note:

• ListBucket and GetBucketLocation must be granted on the bucket itself (the bare bucket ARN, no path) - the service needs them to list directories and find the bucket's region, regardless of path restrictions.
• The object actions (GetObject*, PutObject*, DeleteObject) are what you scope to your chosen prefixes.

Point the verification at a permitted path

When creating the service, the Verify Access step reads and writes a test file. With a path-restricted policy, set the service's Test Path to a directory the policy allows - for example docevent1/ - or verification fails even though your users would be fine.

Restricting users rather than the service

If what you actually want is different users confined to different directories in the same bucket, you do not need IAM for that - give each user a home directory under the service and they cannot escape it.