AWS S3 Permissions
All S3 buckets, objects and subresources are by default private.
Only the Resource owner, not the user who created the resource, can access it.
The AWS account that created the bucket or object can be called the resource owner
If an IAM user creates the bucket/object, the AWS account belonging to the IAM user is the owner of the resource
If the bucket owner grants cross account permissions to other AWS users to upload objects into the buckets, the objects will be owned by the AWS account used to upload the object and not the bucket owners. The following conditions apply:The bucket owner cannot deny access to an object as it is still the bucket buyer who pays for it
The bucket owner can remove or apply archival guidelines to the object and perform restoration
User is the AWS Account user or IAM user who has access to the resource
Bucket owner is an AWS account that created a bucket
The AWS account that uploaded the object to a bucket is called the object owner. It is not the account.
S3 permissions can be classified underResource-based policies and
User policiesUser Policies
IAM with S3 is used by user policies to control access to certain parts of an S3 bucket that an AWS account has.
A User, Group, and Role can always be attached to the User Policy
Anonymous permissions cannot be granted
AWS accounts that own buckets can grant permission to users by using either a bucket policy, or a user policyResource based policies
Access control lists (ACLs), and bucket policies (Policies and Access Control Lists) are resource-based as they are attached to S3 resources.
Bucket policy allows cross-account access for other AWS accounts and IAM users in other accounts.
Bucket policies allow for centralized access control to buckets or objects based on a variety conditions including S3 operations and requesters, resources and aspects of the request (e.g. IP address
AWS accounts that own buckets can grant permission to users by using either a bucket or user policy.
All objects created by the bucket owner are subject to the permissions attached to a bucket
Policies can add or deny permissions to all (or a subset of) objects within a bucket.
Only the bucket owner can associate a policy to a bucket
Bucket policies can be used to grant multipleGranting permissions to multiple account with additional conditions
An anonymous user can be granted read-only permission
Restriction of access to IP addresses
Restricting access to a particular HTTP referer
Restricting access via a specific HTTP header, e.g. to enforce encryption
CloudFront OAI Authorization
To require MFA, add a bucket policy
Cross-account upload permissions are granted while the bucket owner retains full control
Authorizations granted for S3 inventory and Amazon S3 analytics
Permissions granted for S3 Storage LensAccess Control Lists. (ACLs).
Every bucket and object has an associated ACL.
An ACL is a list that identifies grantees and permits granted.
ACLs can be used to grant read/write permissions to resources to other AWS accounts.
ACL supports only limited permissions. You cannot grant conditional permissions.
It is not possible to grant permissions to bucket subresources
An email address or the canonical ID can be used to grant permission to an AWS account. This is just an obscure Account Id. S3 will still locate the canonical user ID for the user if an email address is provided.
Canonical user ID is recommended. Email addresses that are not supported by Canonical are not supported.
Bucket ACLOnly recommended bucket use case is to grant write permission for the S3 Log Delivery Group to write access log objects into the bucket
Bucket ACL will grant write permission for the bucket to the Log D
AWS S3 Permissions