4

Is it possible to allow only write operation to a user to a bucket without the read permissions? The goal to let all my EC2 instances to write each one to a different bucket and not let them to read any other bucket. All my instances are running with the same IAM Role.

Oleg
  • 601
  • 1
  • 8
  • 14

3 Answers3

5

It is certainly possible. For example, I usually use this write-only policy for EC2 instance backup to S3 when using sync command with the --delete switch:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::bucket-name"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": [
                "arn:aws:s3:::bucket-name/*"
            ]
        }
    ]
}
Khalid T.
  • 10,039
  • 5
  • 45
  • 53
4

Yes. You can certainly assign the Role a policy that permits PutObject without any other operation (eg ListBuckets, GetObject).

Option 1: Write-only permissions on a bucket

{ 
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "statement1",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::examplebucket/*"
      ]
    }
  ]
}

Rather than giving each instance its own bucket, you could use the same bucket but use their Instance ID as a directory name (eg s3://my-bucket/i-abcd1234/foo.txt) to avoid filename clashes.

Option 2: Full permissions within a subdirectory

You could even go one step further and give them full access to the Amazon S3 bucket, but only within their own subdirectory.

The Role would be assigned this policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSubdirectory",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket/${aws:userid}/*"
            ]
        }
    ]
}

In this situation, the aws:userid policy variable would be equal to role-id:ec2-instance-id. Thus, the EC2 instance would be able to do anything in the subdirectory (aka Key Prefix) that matches its role and instance ID.

For example:

aws s3 cp foo s3://my-bucket/AROAJCLCJNQ3333ZQLZTW:i-055f66ea41fb4438e/foo

The role-id can be obtained via aws iam get-role --role-name rolename.

This method guarantees that each instance can only use its own subdirectory within the bucket. However, it won't be able to list the contents of the bucket because that is a bucket-level permission.

See also: Granting access to S3 resources based on role name

Community
  • 1
  • 1
John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
  • i liked the option 2, but i wonder if i can add full access permissions to additional user (say the root user) so it will be able to have full access to all the subdirectories and be able to delete them? – Oleg Mar 14 '17 at 07:18
  • 1
    Sure. The above policies would be added to the Role that is assigned to the EC2 instances. You could assign separate permissions to the User or Role that will then read those files that were created. Please note that there is no Bucket Policy required, because we are assigning permissions to Roles and Users, not the bucket itself. – John Rotenstein Mar 14 '17 at 07:20
2

Please be aware that above solutions are correct, but with PutObject Action you can also overwrite existing objects (source). I don't know the exact scenario why you need such type of access, but if you would like to use that for creating backup I would add some extra step to minimize the risk of overwriting objects. I would create a separate process (Lambda for example) to copy all objects from that bucket to another, a safe one, where the client does not have access at all.