Policies

  • User-based

    • IAM policies

  • Resource-based

    • Bucket policies

    • Bucket ACLs

    • Object ACLs

An IAM principal configured in a bucket policy can access an S3 object if BOTH:

  • The user IAM permissions ALLOW it OR the resource policy ALLOWS

  • there’s no explicit DENY

S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to both control ownership of the objects that are uploaded to your bucket and to disable or enable ACLs. By default, Object Ownership is set to the Bucket owner enforced setting, and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to them exclusively by using access-management policies. We recommend that you keep ACLs disabled, except in unusual circumstances where you need to control access for each object individually.

If an AWS account owns a resource, it can grant those permissions to another AWS account. That account can then delegate those permissions, or a subset of them, to users in the account. This is referred to as permission delegation. But an account that receives permissions from another account cannot delegate permission cross-account to another AWS account.

Format

Json document with the following keys:

  • Resource: resource ARN.

  • Action: operation to be performed.

  • Effect: allow or deny.

  • Principal: entity (user, account, service…​) that needs to perform the acion.

  • Condition: a condition.

Resources

AWS ARN

arn:partition:service:region:account-id/relative-id

The region is not needed nor is the namespace (account id) because buckets, even though regioanl, are globally unique.

S3 ARN:

arn:aws:s3:::bucket_name/pre/fix/key_name
arn:aws:s3:::bucket_name/key_name

Principal

Principal ARN:

"AWS":"account-ARN"

# For AWS accounts:

"Principal":{"AWS":"arn:aws:iam::AccountIDWithoutHyphens:root"}

"Principal":{"AWS":["arn:aws:iam::AccountID1WithoutHyphens:root","arn:aws:iam::AccountID2WithoutHyphens:root"]}

"Principal":{"CanonicalUser":"64-digit-alphanumeric-value"}


# For AWS Users
"Principal":{"AWS":"arn:aws:iam::account-number-without-hyphens:user/username"}


# Anonymous permissions
"Principal":{"AWS":"*"}

Action

Condition

Conditional expressions:

"Condition": {
"StringEquals": {
  "s3:x-amz-acl": "public-read"
}

There are global conditions and S3-specific conditions.

Resource-based policies

They’re attached to buckets and define who can do what on what resources.

Bucket policies

Details 
{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid":"GrantAnonymousReadPermissions",
            "Effect":"Allow",
            "Principal": "*",
            "Action":["s3:GetObject"],
            "Resource":["arn:aws:s3:::awsexamplebucket1/*"]
        }
    ]
}

VPC restrictions using bucket policies

You can use Amazon S3 bucket policies to control access to buckets from specific virtual private cloud (VPC) endpoints, or specific VPCs.

A VPC endpoint for Amazon S3 is a logical entity within a VPC that allows connectivity only to Amazon S3

VPC endpoints for Amazon S3 provide two ways to control access to your Amazon S3 data:

  • You can control the requests, users, or groups that are allowed through a specific VPC endpoint. For information about this type of access control, see Controlling Access to Services with VPC Endpoints in the VPC User Guide.

  • You can control which VPCs or VPC endpoints have access to your buckets by using Amazon S3 bucket policies. For examples of this type of bucket policy access control, see the following topics on restricting access.

Specific VPC endpoint allow 
{
   "Version": "2012-10-17",
   "Id": "Policy1415115909152",
   "Statement": [
     {
       "Sid": "Access-to-specific-VPCE-only",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::awsexamplebucket1",
                    "arn:aws:s3:::awsexamplebucket1/*"],
       "Condition": {
         "StringNotEquals": {
           "aws:SourceVpce": "vpce-1a2b3c4d"
         }
       }
     }
   ]
}
Specific VPC allow 
{
   "Version": "2012-10-17",
   "Id": "Policy1415115909153",
   "Statement": [
     {
       "Sid": "Access-to-specific-VPC-only",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::awsexamplebucket1",
                    "arn:aws:s3:::awsexamplebucket1/*"],
       "Condition": {
         "StringNotEquals": {
           "aws:SourceVpc": "vpc-111bbb22"
         }
       }
     }
   ]
}

Bucket-level and Object-level ACLs

Details 
<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>*** Owner-Canonical-User-ID ***</ID>
    <DisplayName>owner-display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:type="Canonical User">
        <ID>*** Owner-Canonical-User-ID ***</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

User policies

IAM policy that regulate access to resources (not only S3). Here principal is always the user. They’re attached to users

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

There are also AWS managed policies for Amazon S3 which are predefined.

Which policies?

When to use an ACL-based access policy (bucket and object ACLs)

Object ACLs:

  • Objects are not owned by the bucket owner

  • You need to manage permissions at the object level

Alternatives to Object ACLs:

  • If the AWS account that owns the object also owns the bucket, it can write a bucket policy to manage the object permissions.

  • If the AWS account that owns the object wants to grant permission to a user in its account, it can use a user policy.

Bucket ACLs: The only recommended use case for bucket ACLs is to grant permissions to certain AWS services like the Amazon CloudFront awslogsdelivery account. When you create or update a distribution and enable CloudFront logging, CloudFront updates the bucket ACL to give the awslogsdelivery account FULL_CONTROL permissions to write logs to your bucket

When to use a bucket policy

If an AWS account that owns a bucket wants to grant permission to users in its account, it can use either a bucket policy or a user policy. However, in the following scenarios, you must use a bucket policy:

  • You want to manage cross-account permissions for all Amazon S3 permissions

When to use a user policy

The permissions to the user can be granted:

  • from the parent account by attaching a user policy.

    • If you want to centralize the policy management

    • If you have many buckets with many policies

  • from the resource owner by using a bucket policy. The resource owner can also grant permissions to the user’s parent account by using a bucket policy, bucket ACL, or object ACL.