24

I have the following IAM policy for a user

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1395161912000",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:PutObject",
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::bucketname"
      ]
    },
    {
      "Sid": "list",
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    }
  ]
}

The goal is to let the user upload files to the bucket, but not overwrite or delete. It's for backup. I started out with ListBucket and PutObject, but added * as it didn't work. Not even * lets the user upload files, just getting Access Denied.

When I try the Simulator, it returns Denied - Implicitly denied (no matching statements found). for ListBucket, which seems odd since I've implicitly allowed that.

I've tried both Cyberduck and 3Hub as S3 clients.

Any idea what's wrong?

kenorb
  • 5,943
  • 1
  • 44
  • 53
Znarkus
  • 1,087
  • 2
  • 18
  • 32

1 Answers1

27

When crafting Amazon IAM policies for Amazon S3, you need to be aware of the difference between Operations on the Service (e.g. ListAllMyBuckets), Operations on Buckets (e.g. ListBucket) and Operations on Objects (e.g. GetObject).

In particular, the Resource specification of your policy needs to address the appropriate target entities according to the following patterns (see e.g. the various Example Policies for Amazon S3):

  • Operations on Service - arn:aws:s3:::*
  • Operations on Buckets - arn:aws:s3:::<bucket>
  • Operations on Objects - arn:aws:s3:::<bucket>/<object>

Solution

You are encountering Access Denied, because you've specified a bucket level resource for PutObject, which requires an object level resource specification like arn:aws:s3:::<bucket>/* - accordingly, the following policy should cover your sample use case:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::bucketname"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::bucketname/*"
      ]
    }
  ]
}
Steffen Opel
  • 5,560
  • 35
  • 55
  • 1
    Amazing, that worked flawlessly. Thank you! So `sid` is not required? – Znarkus Mar 19 '14 at 13:27
  • 1
    According to [Sid](http://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Sid), it is _is an optional identifier that you provide for the policy statement_, which _must be unique within a policy_. Given it seems to work fine w/o (but see below), I tend to remove it here for brevity and when versionizing policies, but do not bother when generating policies automatically for example - however, as per the subsequent **Note**: _Some AWS services (for example, Amazon SQS or Amazon SNS) might require this element [...]_. – Steffen Opel Mar 19 '14 at 15:22
  • 7
    OP says they want "to let the user upload files to the bucket, but not overwrite or delete", but this policy grants `PutObject`, which allows overriding objects, no? I think there's no way to separate that out. – Xiong Chiamiov Jan 19 '17 at 03:16
  • 2
    @XiongChiamiov - the S3 ´PutObject´ action indeed implies overwriting, it's simply how S3 works by default. If you need protection against accidental deletion, you might want to look into [Using versioning](http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) _to preserve, retrieve, and restore every version of every object stored in your Amazon S3 bucket._ - this allows you to _easily recover from both unintended user actions and application failures_. – Steffen Opel Jan 19 '17 at 12:13
  • 5
    Yes, versioning gives you the ability to recover objects that have been overwritten (but you have to discover that they have been, and then go do that). Anyways, -1 because it doesn't provide an accurate answer to the question. – Xiong Chiamiov Jan 19 '17 at 19:41
  • See also: https://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/object-lock-managing.html – romaninsh Jun 04 '20 at 10:17