accept role_session_name from ~/.aws/config

[randxm]

Allows a user to add a role_session_name to their ~/.aws/config file, which will be used in place of the Unix timestamp if available.

[lox]

Thanks for the PR, what's the usecase for this?

This series of comments makes me a bit concerned that there will be unexpected side effects from this: aws/aws-cli#1389 (comment)

[randxm]

The main use case here is that the role_session_name is actually the User name field that appears in AWS CloudTrail logs. While there is no guarantee that a role session name that is used is "accurate" (since it can be set by anyone to be anything), it can help as a first level of "good housekeeping" and can be a lot more informative than a timestamp.

[lox]

Thoughts specifically on the concerns raised in the comment I linked to? We could work around them by appending a timestamp or random number to the role_session_name.

[randxm]

Appreciate the considerations here - I read through the referenced PR and I suppose I didn't directly see a conflict, thanks no doubt to the changes implemented in aws-cli based on that PR. In my testing with the modified code, I observed that modifying the role_session_name led to creating a new session in aws-vault, as expected. e.g., in the logs attached (aws-vault.txt), you can see results from 3 separate runs of aws-vault exec admin-profile -- aws cloudtrail lookup-events --max-results 1.

The first 2 (at 11:12 and 11:15) were made with one role_session_name entered in ~/.aws/config.
The third (at 11:16) was made after the role_session_name was changed.

As you can see, the first two reuse the same session; the third re-required an MFA token and generated a new session. The correct role_session_name for each run was also confirmed in cloudtrail logs.

[lox]

Ok cool, let's merge it in.

[lox]

Thanks for the PR @randxm, apologies it took me a while to QA.