Thanks for your extremely useful feedback.
> I will also echo what others have said: allowing another account access to ours is a non-starter, even if Read-Only. It needs to use a security principal we have complete control over.
You own and control the IAM role, not us. You allow Atlasphere to assume that role, and then Atlasphere's discovery service uses it to discover your resources.
Technically, Atlasphere doesn't need a ton of permissions. If you create a role that can only list, say, Lambda functions, then Atlasphere will only find Lambda functions.
IAM provides a default ReadOnly policy that can be attached to any role. This was the simplest way for me to get things going. But ReadOnly is indeed way too broad. I could generate an IAM policy based on the AWS services that Atlasphere can work with.
> I can tell from this post and the site that this is a labor of love, and I hope you keep up the good work. Like I said, this is an area where we need more, better tools. I want projects like this to succeed.
Thanks a ton! There are mind-blowing features in the roadmap. I want Atlasphere to succeed.
Yes I realized after reading the response that we would control the permissions. What may not be obvious is many organizations have gatekeepers that don't understand IAM and would just not permit this at all.
On the technical side, you are probably underestimating the access you need to accurately gather the information the tool needs. For example, last time I reviewed the AWS-Managed ReadOnly role it does not allow you to read some important things like Managed Prefix Lists.
I completely understand you need a starting point and you picked a good one. Anxious to see how this proceeds. Best of luck.