Do you have any examples or suggestions on how you could modify IAM roles dynamically to be able to upload to another user’s bucket? Or is there any way to create shared shared folder’s with controlled access lists?
I have been looking at different articles, but I’m still not super comfortable with IAM and Cognito so I’m having a bit of trouble figuring out how to share resources between Cognito users in an S3 bucket.
From this stackoverflow post it looks like I should be managing shared resources through the app itself and can grant access to resources using presigned urls. Is that a good approach to this problem, or are there some existing IAM / Cognito strategies that I am overlooking?
Are your resources being created via the serverless.yml? Or were they created through the AWS console?
I think the answer in the Stack Overflow post makes sense. I would go with that. Creating groups in Cognito is a lot more complicated.
When creating the Identity Pool, we have the opportunity to create IAM roles for users. In this chapter, we use IAM roles to give users access to invoke certain API endpoints and the ability to upload to S3. How could we access/enforce a users IAM role from within the lambda function?
For example, let’s say we want to create an IAM policy that restricts which items in DynamoDB are editable by the user. A good example would be updating a note in the notes app. How could the IAM policy defined in Cognito be applied from within our lambda code when making the call to update an item in DynamoDB? Is there a way to tell API gateway to inherit the role defined by the caller of the function?
So this one is a bit tricky AFAIK. There are some way to do this. Where the IAM role that the Lambda functions use, checks the Cognito Identity Pool user id and decides if the function can be accessed. I don’t think there is a way to pass the role info along to the Lambda functions.
However, the far easier way is to just manage this within your application. Check against your DB and decide if the user is allowed to perform the requested action.
Thanks for confirming what I’ve suspected. IAM seems like the perfect tool for this situation, but I’m finding it simply isnt meant to enforce application specific authorization logic that I’m describing. While it may technically be able to do so with some cleverness, I agree that enforcing these rules from within the application logic seems like the way to go.