Q: do you apply policy on roles, resources, or both? How do you maintain mental sanity?<p>We use 1 base policy + 1 policy/role, and so for each role it's easy to see what are its permissions.<p>We have no policy on resources, so it's hard, e.g., given a bucket to know who has access to it. We're building tooling for that.<p>edit: grammar/typos
There's been lots of griping about AWS and IAM, which I'm sure is at least in part due to AWS' popularity, but how does it compare to permissions management from other major cloud providers, e.g. google and azure?
When you switch roles in the console, you don't have to enter in your credentials. So, if I get access to the account, I have access to all the roles. So, what additional protection is provided by separating out permissions into roles that are trivially accessible?<p>I can see how if conditions are added to the AccessRole action, such that I can only switch roles based on time of day or IP address, then that might be useful (although those conditions could be applied directly to policies as well).<p>So, absent the conditions mention above (which is still questionable), is there any point to using roles in the console?
Isn't the "Principal" element only a part of S3 permission policies, not IAM? In IAM the "principal" is implied, it's the user to which the policy is attached. Edit: I see you explain well into the article, but I believe the title of the article could be improved.