It was mentioned and explained in the course that ACLs provide Object-level access control, whereas the Bucket Resource Policy is mostly meant for access to the entire Bucket as a whole.
I will quote from the lecture "S3 ACLs":
"However, if you need to apply policies on the objects themselves, then use S3 ACL’s". Bucket policies can only be applied at the bucket level where as S3 ACL’s can be applied to individual files (objects).
This is wrong.
A bucket resource policy CAN be applied to a specific object. In fact, this is done through the resource and principal elements of the Bucket Policy. Here is an example (denies all access, including the root-user, to a specific object):
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "S3 object-level access",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::some_s3_bucket/image1.jpg"
}
]
}
Or it can also be done for a specific IAM user:
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "S3 object-level access",
"Effect": "Deny",
"Principal": "arn:aws:iam::111222333444:user/Bob",
"Action": "s3:*",
"Resource": "arn:aws:s3:::some_s3_bucket/image1.jpg"
}
]
}
It is actually better to use the bucket resource policy over the S3 ACL because it can be used to "Deny" access to an object (something that cannot be done with an S3 ACL), as well as contain multiple principles/resources within the policy. Lastly, it can enforce things like 2FA, granularity over the Action element, restrictions by IPs, and much more than S3 ACLs can ever do.
Agreed! https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/#:~:text=As%20a%20general%20rule%2C%20AWS,control%20mechanism%20that%20predates%20IAM.&text=You%20can%20attach%20S3%20ACLs,manage%20permissions%20for%20those%20objects.
The video also implies that you can get cannonical IDs for individual IAM Users, but that appears to be untrue as well. There is one cannonical ID per account.