Looks like the role generated for group crud access doesn't honor the private / protected concept that applies for the authenticated role. The auth role in cognito has rules matching cognito:sub guid etc but the role for cognito group has full access to the whole bucket and subdirs. When adding group crud access with cli, a role with full access is generated. Anyone else have encountered this? Suggestions?
#Group access doesn't honor private / protected for s3 storage
5 messages · Page 1 of 1 (latest)
Ideally CLI prompt you the permission you would like to configure for group access like group name and read/write/delete etc. Can you share the complete workflow how you are configuring permissions ? Remove sensitive information if any
Hi. Sorry for late reply. the cli options work as they should; I can set crud per auth, unauth and group. The problem is that if group has all acces, the public, protected, private concept of amplify storage is shortcutted. i.e. users in the group have full access to public, protected, private folders in the s3 bucket, bupassing the policies on auth iam role (which has policies limiting access). the group role in iam has no policies attached.
If I, in the cli set auth users to only create, update, delete (not read) and a cognito group to only read, the auth role gets policies that honors the concept of public protected and private, but the group role policy does not (note the star, this policy allows reading "[bucket_name]/private", which defeats the Amplify distinction of public, protected and private as described here (https://docs.amplify.aws/lib/storage/configureaccess/q/platform/js/) ;
This is the role policy that gets generated;{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "arn
s3:::[BUCKET_NAME]/*",
"Effect": "Allow"
},
{
"Action": "s3:ListBucket",
"Resource": "arn
s3:::[BUCKET_NAME]",
"Effect": "Allow"
}
]
}