AWS S3 Permissions

• By default, all S3 buckets, objects, and related subresources are private.
• Only the Resource owner, the AWS account (not the user) that creates the resource, can access the resource.
• Resource owner can be
  • AWS account that creates the bucket or object owns those resources
  • If an IAM user creates the bucket or object, the AWS account of the IAM user owns the resource
  • If the bucket owner grants cross-account permissions to other AWS account users to upload objects to the buckets, the objects are owned by the AWS account of the user who uploaded the object and not the bucket owner except for the following conditions
    • Bucket owner can deny access to the object, as it is still the bucket owner who pays for the object
    • Bucket owner can delete or apply archival rules to the object and perform restoration
• User is the AWS Account or the IAM user who access the resource
• Bucket owner is the AWS account that created a bucket
• Object owner is the AWS account that uploads the object to a bucket, not owned by the account
• S3 permissions are classified into
  • Resource based policies and
  • User policies

S3 Object Ownership

• S3 Object Ownership is a bucket-level setting that controls ownership of objects uploaded to the bucket and allows disabling or enabling ACLs.
• By default (since April 2023), Object Ownership is set to Bucket owner enforced and all ACLs are disabled for all new buckets.
• A majority of modern use cases in S3 no longer require ACLs, and AWS recommends keeping ACLs disabled.
• With ACLs disabled, the bucket owner owns all objects and manages access exclusively using policies (IAM policies, bucket policies, access point policies).
• Object Ownership has three settings:
  • Bucket owner enforced (default) – ACLs are disabled. The bucket owner automatically owns and has full control over every object. ACLs no longer affect permissions. The bucket uses policies exclusively for access control.
  • Bucket owner preferred – ACLs are enabled. The bucket owner owns new objects written with the bucket-owner-full-control canned ACL. Objects uploaded with other ACLs are owned by the writing account.
  • Object writer – ACLs are enabled. The AWS account that uploads an object owns it and can grant access via ACLs.
• When ACLs are disabled (Bucket owner enforced):
  • All bucket and object ACLs are disabled, giving full access only to the bucket owner
  • The bucket owner automatically owns and has full control over every object
  • ACLs no longer affect access permissions; access control is based on IAM policies, bucket policies, VPC endpoint policies, and Organizations SCPs/RCPs
  • Requests to set or update ACLs fail, but requests to read ACLs are still supported
  • Only PUT requests that don’t specify an ACL or specify bucket-owner-full-control are accepted
• ACLs can be re-enabled at any time by changing to another Object Ownership setting, and preexisting ACLs are restored.
• For S3 Replication across accounts, the Bucket owner enforced setting automatically changes replica ownership to the destination bucket owner without needing the s3:ObjectOwnerOverrideToBucketOwner permission.
• Permissions required: s3:PutBucketOwnershipControls to set, s3:GetBucketOwnershipControls to view.

S3 Block Public Access

• S3 Block Public Access provides controls to ensure that S3 resources never have public access.
• Since April 2023, Block Public Access is enabled by default for all newly created buckets in all AWS Regions.
• Block Public Access can be applied at three levels:
  • Bucket level – applies to a specific bucket and its objects
  • Account level – applies to all buckets in the AWS account (current and future)
  • Organization level – centrally managed via AWS Organizations policies across all member accounts
• Block Public Access settings override S3 permissions that allow public access, regardless of how an object is added or bucket is created.
• Four settings are available:
  • BlockPublicAcls – blocks PUT requests that include public ACLs for buckets and objects
  • IgnorePublicAcls – ignores all public ACLs on a bucket and its objects
  • BlockPublicPolicy – rejects bucket policy changes that grant public access
  • RestrictPublicBuckets – restricts access to buckets with public policies to only AWS service principals and authorized users
• S3 takes the most restrictive combination of bucket-level, account-level, and organization-level settings.
• AWS recommends turning on “Block all public access” unless public access is explicitly required for specific use cases.

User Policies

• User policies use IAM with S3 to control the type of access a user or group of users has to specific parts of an S3 bucket the AWS account owns
• User policy is always attached to a User, Group, or a Role
• Anonymous permissions cannot be granted
• 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

Resource-Based policies

• Bucket policies and access control lists (ACLs) are resource-based because they are attached to the S3 resources

Bucket Policies

• Bucket policy can be used to grant cross-account access to other AWS accounts or IAM users in other accounts for the bucket and objects in it.
• Bucket policies provide centralized, access control to buckets and objects based on a variety of conditions, including S3 operations, requesters, resources, and aspects of the request (e.g. IP address)
• 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
• Permissions attached to a bucket apply to all of the objects in that bucket created and owned by the bucket owner
• Policies can either add or deny permissions across all (or a subset) of objects within a bucket
• Only the bucket owner is allowed to associate a policy with a bucket
• Bucket policies can cater to multiple use cases
  • Granting permissions to multiple accounts with added conditions
  • Granting read-only permission to an anonymous user
  • Limiting access to specific IP addresses
  • Restricting access to a specific HTTP referer
  • Restricting access to a specific HTTP header for e.g. to enforce encryption
  • Granting permission to a CloudFront OAI
  • Adding a bucket policy to require MFA
  • Granting cross-account permissions to upload objects while ensuring the bucket owner has full control
  • Granting permissions for S3 inventory and Amazon S3 analytics
  • Granting permissions for S3 Storage Lens

Access Control Lists (ACLs)

• Note: Since April 2023, ACLs are disabled by default for all newly created S3 buckets (Object Ownership set to “Bucket owner enforced”). AWS recommends keeping ACLs disabled and using bucket policies instead for the majority of use cases.
• Each bucket and object has an ACL associated with it.
• An ACL is a list of grants identifying grantee and permission granted
• ACLs are used to grant basic read/write permissions on resources to other AWS accounts.
• ACL supports limited permissions set and
  • cannot grant conditional permissions, nor can you explicitly deny permissions
  • cannot be used to grant permissions for bucket subresources
• Permission can be granted to an AWS account by the email address or the canonical user ID (is just an obfuscated Account Id). If an email address is provided, S3 will still find the canonical user ID for the user and add it to the ACL.
• It is Recommended to use Canonical user ID as email address would not be supported
• Bucket ACL
  • Only recommended use case for the bucket ACL is to grant write permission to the S3 Log Delivery group to write access log objects to the bucket
  • Bucket ACL will help grant write permission on the bucket to the Log Delivery group if access log delivery is needed to the bucket
  • Only way you can grant necessary permissions to the Log Delivery group is via a bucket ACL
• Object ACL
  • Object ACLs control only Object-level Permissions
  • Object ACL is the only way to manage permission to an object in the bucket not owned by the bucket owner i.e. If the bucket owner allows cross-account object uploads and if the object owner is different from the bucket owner, the only way for the object owner to grant permissions on the object is through Object ACL
  • If the Bucket and Object is owned by the same AWS account, Bucket policy can be used to manage the permissions
  • If the Object and User is owned by the same AWS account, User policy can be used to manage the permissions
  • With Bucket owner enforced (default), cross-account object ownership issues are eliminated as the bucket owner automatically owns all objects

S3 Access Points

• S3 Access Points are named network endpoints attached to buckets that simplify managing data access at scale for shared datasets.
• Each access point has its own access point policy and can enforce distinct permissions and network controls for any request made through it.
• Access point policies work in conjunction with the underlying bucket policy.
• A bucket can have thousands of access points per AWS Region per account, each with a policy up to 20 KB.
• Access points can only be used to perform object operations (GetObject, PutObject, etc.), not bucket operations like deleting buckets or configuring replication.
• Network Controls:
  • Access points can be configured to accept requests only from a specific Virtual Private Cloud (VPC), restricting S3 data access to a private network.
  • Custom Block Public Access settings can be configured for each access point independently.
• Use Cases:
  • Managing access for shared datasets (data lakes, media archives, user-generated content)
  • Creating individualized access points with permissions customized per application, team, or user
  • Simplifying complex bucket policies by distributing access rules across multiple access points
  • Restricting data access to specific VPCs for security compliance
• S3 Multi-Region Access Points:
  • Provide a single global endpoint to access replicated datasets across multiple AWS Regions
  • Dynamically route requests via AWS Global Accelerator, reducing latency by up to 60%
  • Include failover controls for active-passive or active-active configurations
  • Allow shifting S3 data access request traffic between AWS Regions at any time
• Access points are referenced using ARNs, access point aliases, or virtual-hosted-style URIs.

S3 Access Grants

• S3 Access Grants (launched November 2023) provides a simplified model for defining access permissions to S3 data by prefix, bucket, or object.
• Supports up to 100,000 grants per Region per account.
• Grants access to both IAM principals and directly to users or groups from corporate directories (Microsoft Entra ID, Okta, Ping).
• Key Capabilities:
  • Define direct access mappings of S3 prefixes to users and roles
  • Grant read-only, write-only, or read-write access on a per-prefix basis
  • Integrate with AWS IAM Identity Center for trusted identity propagation
  • End-user identities propagated to S3, simplifying audit via CloudTrail data events
  • Cross-account access support without frequent IAM policy updates
• When to Use S3 Access Grants:
  • Bucket policy size limit (20 KB) is being reached
  • Granting corporate directory users/groups (Entra ID, Okta) access to S3 data for analytics
  • Cross-account access is needed without frequent policy updates
  • Data access is unstructured and object-level rather than row/column format
• Components:
  • Access Grants Instance – container for grants, one per Region per account
  • Locations – registered S3 paths (default s3://, bucket, or prefix) with an IAM role
  • Grants – individual access mappings from a grantee to an S3 location with a permission level
• Applications request temporary credentials from S3 Access Grants on behalf of the authenticated user.
• Integrates with AWS services including Amazon SageMaker, Amazon Redshift, and AWS Glue.

S3 Request Authorization

When S3 receives a request, it must evaluate all the user policies, bucket policies, and ACLs to determine whether to authorize or deny the request.

S3 evaluates the policies in 3 context

• User context is basically the context in which S3 evaluates the User policy that the parent AWS account (context authority) attaches to the user
• Bucket context is the context in which S3 evaluates the access policies owned by the bucket owner (context authority) to check if the bucket owner has not explicitly denied access to the resource
• Object context is the context where S3 evaluates policies owned by the Object owner (context authority)

Analogy

• Consider 3 Parents (AWS Account) A, B and C with Child (IAM User) AA, BA and CA respectively
• Parent A owns a Toy box (Bucket) with Toy AAA and also allows toys (Objects) to be dropped and picked up
• Parent A can grant permission (User Policy OR Bucket policy OR both) to his Child AA to access the Toy box and the toys
• Parent A can grant permissions (Bucket policy) to Parent B (different AWS account) to drop toys into the toys box. Parent B can grant permissions (User policy) to his Child BA to drop Toy BAA
• Parent B can grant permissions (Object ACL) to Parent A to access Toy BAA
• Parent A can grant permissions (Bucket Policy) to Parent C to pick up the Toy AAA who in turn can grant permission (User Policy) to his Child CA to access the toy
• Parent A can grant permission (through IAM Role) to Parent C to pick up the Toy BAA who in turn can grant permission (User Policy) to his Child CA to access the toy

Bucket Operation Authorization

1. If the requester is an IAM user, the user must have permission (User Policy) from the parent AWS account to which it belongs
2. Amazon S3 evaluates a subset of policies owned by the parent account. This subset of policies includes the user policy that the parent account attaches to the user.
3. If the parent also owns the resource in the request (in this case, the bucket), Amazon S3 also evaluates the corresponding resource policies (bucket policy and bucket ACL) at the same time.
4. Requester must also have permissions (Bucket Policy or ACL) from the bucket owner to perform a specific bucket operation.
5. Amazon S3 evaluates a subset of policies owned by the AWS account that owns the bucket. The bucket owner can grant permission by using a bucket policy or bucket ACL.
6. Note that, if the AWS account that owns the bucket is also the parent account of an IAM user, then it can configure bucket permissions in a user policy or bucket policy or both

Object Operation Authorization

1. If the requester is an IAM user, the user must have permission (User Policy) from the parent AWS account to which it belongs.
2. Amazon S3 evaluates a subset of policies owned by the parent account. This subset of policies includes the user policy that the parent attaches to the user.
3. If the parent also owns the resource in the request (bucket, object), Amazon S3 evaluates the corresponding resource policies (bucket policy, bucket ACL, and object ACL) at the same time.
4. If the parent AWS account owns the resource (bucket or object), it can grant resource permissions to its IAM user by using either the user policy or the resource policy.
5. S3 evaluates policies owned by the AWS account that owns the bucket.
6. If the AWS account that owns the object in the request is not the same as the bucket owner, in the bucket context Amazon S3 checks the policies if the bucket owner has explicitly denied access to the object.
7. If there is an explicit deny set on the object, Amazon S3 does not authorize the request.
8. Requester must have permissions from the object owner (Object ACL) to perform a specific object operation.
9. Amazon S3 evaluates the object ACL.
10. If bucket and object owners are the same, access to the object can be granted in the bucket policy, which is evaluated in the bucket context.
11. If the owners are different, the object owners must use an object ACL to grant permissions.
12. If the AWS account that owns the object is also the parent account to which the IAM user belongs, it can configure object permissions in a user policy, which is evaluated in the user context.

Permission Delegation

• 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.
• If the Bucket owner wants to grant permission to the Object which does not belong to it to another AWS account it cannot do it through cross-account permissions and need to define an IAM role which can be assumed by the AWS account to gain access

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. Which features can be used to restrict access to data in S3? Choose 2 answers
   1. Set an S3 ACL on the bucket or the object.
   2. Create a CloudFront distribution for the bucket.
   3. Set an S3 bucket policy.
   4. Enable IAM Identity Federation
   5. Use S3 Virtual Hosting
2. Which method can be used to prevent an IP address block from accessing public objects in an S3 bucket?
   1. Create a bucket policy and apply it to the bucket
   2. Create a NACL and attach it to the VPC of the bucket
   3. Create an ACL and apply it to all objects in the bucket
   4. Modify the IAM policies of any users that would access the bucket
3. A user has granted read/write permission of his S3 bucket using ACL. Which of the below mentioned options is a valid ID to grant permission to other AWS accounts (grantee) using ACL?
   1. IAM User ID
   2. S3 Secure ID
   3. Access ID
   4. Canonical user ID
4. A root account owner has given full access of his S3 bucket to one of the IAM users using the bucket ACL. When the IAM user logs in to the S3 console, which actions can he perform?
   1. He can just view the content of the bucket
   2. He can do all the operations on the bucket
   3. It is not possible to give access to an IAM user using ACL
   4. The IAM user can perform all operations on the bucket using only API/SDK
5. A root AWS account owner is trying to understand various options to set the permission to AWS S3. Which of the below mentioned options is not the right option to grant permission for S3?
   1. User Access Policy
   2. S3 Object Policy
   3. S3 Bucket Policy
   4. S3 ACL
6. A system admin is managing buckets, objects and folders with AWS S3. Which of the below mentioned statements is true and should be taken in consideration by the sysadmin?
   1. Folders support only ACL
   2. Both the object and bucket can have an Access Policy but folder cannot have policy
   3. Folders can have a policy
   4. Both the object and bucket can have ACL but folders cannot have ACL
7. A user has created an S3 bucket which is not publicly accessible. The bucket is having thirty objects which are also private. If the user wants to make the objects public, how can he configure this with minimal efforts?
   1. User should select all objects from the console and apply a single policy to mark them public
   2. User can write a program which programmatically makes all objects public using S3 SDK
   3. Set the AWS bucket policy which marks all objects as public
   4. Make the bucket ACL as public so it will also mark all objects as public
8. You need to configure an Amazon S3 bucket to serve static assets for your public-facing web application. Which methods ensure that all objects uploaded to the bucket are set to public read? Choose 2 answers
   1. Set permissions on the object to public read during upload.
   2. Configure the bucket ACL to set all objects to public read.
   3. Configure the bucket policy to set all objects to public read.
   4. Use AWS Identity and Access Management roles to set the bucket to public read.
   5. Amazon S3 objects default to public read, so no action is needed.
9. Amazon S3 doesn’t automatically give a user who creates _____ permission to perform other actions on that bucket or object.
   1. a file
   2. a bucket or object
   3. a bucket or file
   4. a object or file
10. A root account owner is trying to understand the S3 bucket ACL. Which of the below mentioned options cannot be used to grant ACL on the object using the authorized predefined group?
    1. Authenticated user group
    2. All users group
    3. Log Delivery Group
    4. Canonical user group
11. A user is enabling logging on a particular bucket. Which of the below mentioned options may be best suitable to allow access to the log bucket?
    1. Create an IAM policy and allow log access
    2. It is not possible to enable logging on the S3 bucket
    3. Create an IAM Role, which has access to the log bucket
    4. Provide ACL for the logging group
12. A user is trying to configure access with S3. Which of the following options is not possible to provide access to the S3 bucket / object?
    1. Define the policy for the IAM user
    2. Define the ACL for the object
    3. Define the policy for the object
    4. Define the policy for the bucket
13. A user is having access to objects of an S3 bucket, which is not owned by him. If he is trying to set the objects of that bucket public, which of the below mentioned options may be a right fit for this action?
    1. Make the bucket public with full access
    2. Define the policy for the bucket
    3. Provide ACL on the object
    4. Create an IAM user with permission
14. A bucket owner has allowed another account’s IAM users to upload or access objects in his bucket. The IAM user of Account A is trying to access an object created by the IAM user of account B. What will happen in this scenario?
    1. The bucket policy may not be created as S3 will give error due to conflict of Access Rights
    2. It is not possible to give permission to multiple IAM users
    3. AWS S3 will verify proper rights given by the owner of Account A, the bucket owner as well as by the IAM user B to the object
    4. It is not possible that the IAM user of one account accesses objects of the other IAM user
15. A company creates a new S3 bucket using default settings. What security features are automatically enabled? [Choose 2 answers]
    1. S3 Block Public Access is enabled
    2. Server-side encryption with customer-managed KMS keys
    3. ACLs are disabled (Object Ownership set to Bucket owner enforced)
    4. S3 Object Lock is enabled
    5. Cross-Region Replication is enabled
16. A company has a shared data lake in S3 accessed by multiple teams. They want to simplify access management without complex bucket policies. Which approach is most appropriate?
    1. Create separate buckets for each team
    2. Create S3 Access Points with individualized policies per team
    3. Use S3 ACLs for each team’s objects
    4. Create one large bucket policy with all team permissions
17. A company needs to grant corporate directory users (Microsoft Entra ID) access to specific S3 prefixes for analytics workloads without mapping each user to an IAM principal. Which S3 feature should they use?
    1. S3 Bucket Policies with IAM federation
    2. S3 Access Points
    3. S3 Access Grants
    4. S3 ACLs with canonical user IDs
18. An organization wants to restrict S3 data access to requests originating only from within their VPC. Which feature allows creating an S3 endpoint that enforces VPC-only access?
    1. S3 Bucket Policy with VPC condition key
    2. S3 Access Point configured with VPC network origin
    3. S3 Block Public Access at account level
    4. S3 Object Ownership with Bucket owner enforced
19. With S3 Object Ownership set to “Bucket owner enforced”, what happens when another AWS account uploads an object to the bucket?
    1. The upload fails unless the uploader specifies an ACL
    2. The uploading account retains ownership of the object
    3. The bucket owner automatically owns the object and ACLs have no effect
    4. The object is placed in a pending state until the bucket owner approves it

References

• AWS S3 Access Control
• S3 Object Ownership
• S3 Block Public Access
• S3 Access Points
• S3 Access Grants