Hey everyone! I'm currently building a static website using S3 and I thought S3 could assume roles to access other AWS resources. I've learned some things the hard way. For now, I'm using an IAM user to read from a specific bucket and I've stored the credentials in a JS config file (not great, I know!). The bucket isn't public, but its contents are displayed on my site and there's no sensitive info at stake.
For some limited write access through API Gateway, I'm considering having a separate bucket that contains credentials and the API Gateway URL. The previous IAM user can read from this new bucket, but it won't be defined in the code; the user has to input it instead. My reasoning is that unless someone brute-forces it, they won't know the bucket name.
I plan to switch to Cognito for writes later since I don't want to use it for reads right now due to costs. Here's the kicker: the write webpage is locked by a passphrase that checks for the existence of a bucket with the same name, so it's a bit of a hack. I feel like this is a weak point that will eventually require Cognito for better security. I'd love to hear your thoughts on this setup and its potential risks!
2 Answers
Please, just don’t do this. There's no benefit to overcomplicating your setup like that. Using IAM users for S3 directly can lead to a lot of potential issues. You should really consider implementing Aquino for something a lot simpler and more secure!
What's the reasoning behind this choice? It seems like you're making the process harder without any clear advantages. You've essentially ruled out the main benefits of using Cognito, which could simplify your authentication and authorization.
Lol, I just migrated from Firebase and I'm trying to adapt to AWS. I didn’t consider that I could treat files like directories. This puts things in a different light!