3 ms·

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

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? 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). So, absent the conditions mention above (which is still questionable), is there any point to using roles in the console?

andrewguenther 10y ago
This is where users come in. You should be setting up users other than the root user which have significantly fewer permissions. We essentially use our root user to set up the account and then throw away the MFA key (not really, but you get the idea). As for roles themselves in the console, those become useful when you're using federation: https://aws.amazon.com/iam/details/manage-federation/ https://aws.amazon.com/iam/details/manage-federation/ This allows you to use your company's own identity provider instead of IAM users (or in conjunction with). In this scenario, users access the console by assuming a role. You essentially say "Users within this Active Directory group are allowed to access the console by assuming this role." This process uses Active Directory to communicate with STS to give you a temporary token allowing you to assume the role: http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html http://docs.aws.amazon.com/STS/latest/APIReference/API_Assum... The diagram on this page provides a nice overview of how that all ends up working: https://aws.amazon.com/code/4001165270590826 https://aws.amazon.com/code/4001165270590826

andrewguenther 10y ago

This is where users come in. You should be setting up users other than the root user which have significantly fewer permissions. We essentially use our root user to set up the account and then throw away the MFA key (not really, but you get the idea). As for roles themselves in the console, those become useful when you're using federation: https://aws.amazon.com/iam/details/manage-federation/ https://aws.amazon.com/iam/details/manage-federation/ This allows you to use your company's own identity provider instead of IAM users (or in conjunction with). In this scenario, users access the console by assuming a role. You essentially say "Users within this Active Directory group are allowed to access the console by assuming this role." This process uses Active Directory to communicate with STS to give you a temporary token allowing you to assume the role: http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html http://docs.aws.amazon.com/STS/latest/APIReference/API_Assum... The diagram on this page provides a nice overview of how that all ends up working: https://aws.amazon.com/code/4001165270590826 https://aws.amazon.com/code/4001165270590826