Add ability to use role ARN as configuration variable #667
Conversation
…iables for cross-account access instead of account-specific keys
|
This is interesting. I've also been trying to figure out the best way to assume IAM roles in the AWS CLI. You might want to check out #656. My original implementation added the role ARN to the profile just as yours does so you would have to supply a That approach, however, also causes problems because it's difficult to lock that session to a particular TTY session in a platform-independent way so it affects all use of the CLI. Also, I feel it would be easy for someone to forget they have a session started and doing something they didn't intend to do. So, I like your approach better of requiring an explicit command line option or environment variable. If we combine this with the ability in botocore to cache and automatically refresh temporary credentials I think it would be very useful. |
|
Thanks for the feedback. I agree that using a role (or any credentials other than default for that matter) without some explicit indication that you want to do so could be pretty troublesome. I am not familiar with botocore's ability to cache and refresh temporary credentials but that sounds like what I was looking for. I will have to poke around a bit and see if I can figure out how that works. |
|
The ability to manage temporary credentials has not yet been merged into botocore. You can find the current implementation in boto/botocore#226. This implementation assumes that one session is active at any time and it manages that single session. What I am thinking of doing is modifying this PR to allow multiple sets of temporary credentials to be cached at a time. Each set of temporary credentials would represent one assumed role specified in the config file and you could select any of these by specifying the appropriate profile name. In addition to allowing a profile to contain a |
|
Thanks for the info. That all sounds like a great plan. I was thinking that MFA support would be a nice addition but I hadn't gotten to the point of looking into it yet. Time to start I guess ;) |
This builds on the work of several existing pull requests combining what I believe is the combination of all the suggested changes including: * Use role_arn to trigger assume role behavior. Do not require an explicit session to be created and ended (aws#667). * Cache the temporary credentials. If the credentials are not expired then we should reuse them instead of making the assume role call every time (aws#656 and boto/botocore#226). I think a strong case can be made to move this to botocore. However, the file caching makes me somewhat hesitant to move this into botocore (but I think the AssumeRoleProvider without the caching could be added to botocore). I'd like to evaluate this in the future but for now, I don't think it's unreasonable to leave this in the AWS CLI for the time being. At any rate, this is a straightforward and compatible move if we decide to do so. Also, the ability to open a browser with the currently scoped session has not been ported over. I'd like to address that in a separate pull request.
This builds on the work of several existing pull requests combining what I believe is the combination of all the suggested changes including: * Use role_arn to trigger assume role behavior. Do not require an explicit session to be created and ended (aws#667). * Cache the temporary credentials. If the credentials are not expired then we should reuse them instead of making the assume role call every time (aws#656 and boto/botocore#226). I think a strong case can be made to move this to botocore. However, the file caching makes me somewhat hesitant to move this into botocore (but I think the AssumeRoleProvider without the caching could be added to botocore). I'd like to evaluate this in the future but for now, I don't think it's unreasonable to leave this in the AWS CLI for the time being. At any rate, this is a straightforward and compatible move if we decide to do so. Also, the ability to open a browser with the currently scoped session has not been ported over. I'd like to address that in a separate pull request.
|
Closing out, superseded by 22932e5 |
My group at work needs to access a number of AWS accounts so we setup cross-account roles (http://docs.aws.amazon.com/IAM/latest/UserGuide/cross-acct-access.html) to allow us to use our existing IAM user accounts instead of creating IAM users in each AWS account. To simplify accessing these roles, I have added a configuration variable named role_arn to aws-cli. This can be used in a profile in place of access key ids and secrets. When a profile that is configured with a role_arn is invoked by the CLI, the access key id and secret from the default profile will be used to retrieve temporary security credentials for the role from STS and then the requested CLI command will be performed with said credentials.
The one thing about how this works that feels a little "dirty" to me is that new temporary credentials are retrieved each time the CLI is run with a role_arn profile, even if valid credentials already exist for the profile. I am fairly new to the AWS API and this is my first real attempt at Python programming so there might be a better way to handle that but I didn't see anything that appeared to address the situation when I looked at the STS documentation. One alternative would be to store the temporary credentials to a file but that seemed like a departure from how any other part of aws-cli works.
Thanks for your time. I appreciate any feedback you have about this addition and its implementation.