Using S3 Access Control Lists (ACLs) for Managing Permissions in Multiple AWS Accounts
Question
You are an AWS administrator in an IT company.
You need to manage a large number of S3 buckets across multiple AWS accounts.
These S3 buckets should have different access policies, and you are considering using S3 access control lists (ACLs) to manage the permissions.
Among the following situations, which of them can you use S3 ACLs to configure? (Select TWO.)
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D. E.Correct Answer - C, E.
S3 access control lists (ACLs) belong to resource-based access policies, and it is a legacy access control mechanism that predates IAM.
The introductions of ACLs can be found in https://docs.aws.amazon.com/AmazonS3/latest/dev/S3_ACLs_UsingACLs.html.
Option A is incorrect: In ACLs, you can grant permissions only to AWS accounts.
You cannot select an IAM user in an S3 ACL.
Option B is incorrect: Unlike S3 bucket policies, you cannot create an ACL policy with a condition.
Option C is CORRECT: The access for other AWS accounts can be granted as below snapshot:
Option D is incorrect: Because explicit deny is not configurable in S3 ACLs.
Users can only add explicit allows in ACLs.
Option E is CORRECT: Read public access is configurable.
Take the below screenshot as an example:
S3 ACLs (Access Control Lists) are a legacy method of managing permissions on S3 buckets and objects. They are generally not recommended for use, as they are difficult to manage and do not provide the same level of functionality as other AWS IAM policies.
However, in certain situations, S3 ACLs can be used to configure permissions on S3 buckets. Let's examine the given scenarios to determine which of them are suitable for using S3 ACLs:
A. Grant read-only permissions to an IAM user who belongs to a third-party AWS account. The user needs the read access for audit purposes.
This scenario can be achieved using S3 ACLs. You can create an S3 ACL that grants read-only access to the specific IAM user or IAM role belonging to the third-party AWS account. This will allow the user or role to access the bucket and its contents, but only in a read-only capacity.
C. A bucket allows 10 other AWS accounts to list, create and delete their objects.
This scenario can also be achieved using S3 ACLs. You can create an S3 ACL that grants list, create, and delete permissions to the specific AWS accounts that need access to the bucket. This will allow the accounts to access the bucket and its contents, but only with the specific permissions granted in the S3 ACL.
B, D, and E cannot be achieved using S3 ACLs:
B. Allow the permission of S3:PutObject on the condition that the server-side encryption with SSE-KMS is requested.
This scenario requires the use of an S3 bucket policy, not an S3 ACL. A bucket policy can be used to specify conditions for granting permissions, such as requiring SSE-KMS encryption.
D. Explicit deny other AWS accounts to read or write the bucket permissions to prevent other accounts from modifying them.
This scenario also requires the use of an S3 bucket policy, not an S3 ACL. An explicit deny can be used in a bucket policy to prevent specific AWS accounts from accessing or modifying the bucket's permissions.
E. Enable public access for an S3 bucket. The access is read-only and the write permission is still not granted to the public.
This scenario requires the use of a bucket policy, not an S3 ACL. A bucket policy can be used to grant or deny public access to a bucket or object.
In summary, S3 ACLs can be used to grant specific permissions to IAM users and roles belonging to third-party AWS accounts or to allow specific AWS accounts to access an S3 bucket with specific permissions. However, for scenarios that require more advanced functionality, such as specifying conditions for permissions or denying access, an S3 bucket policy should be used instead.
