WIP Commit.

[garnaat]

This is not ready for prime time yet. Also, this depends on boto/botocore#226.

I have session start/end working and also the launching of the web console with session credentials. Needs lots of cleanup and tests and support for federated and SAML credentials. I am using this at the moment with a lot of assumed roles using an IAM account in the dev environment that is authorized to assume certain roles in the prod environment. It's actually working pretty well and being able to launch the web console with the temporary credentials is really nice.

I don't like how you have to remember the ARN of the role you want to assume. It would be much nicer to be able to provide easy-to-remember names for roles in the config file. Perhaps something like:

[Roles]
myrole1 = ARN of IAM Role

Also, I'm still not 100% sold on the modal nature of this. You basically start a session via AssumeRole or some other mechanism and then everything you do with the CLI until you end the session is with those credentials. The alternative would be to allow for multiple named sessions and to require the user to specify a --session-name option to explicitly use a session for each command. That's kind of a pain and I think I like the start/end idea better but it can be kind of dangerous if you forget you started a session.

[markpeek]

We talked a little about this at re:invent so you know I'm very aligned with seeing this go in and glad you made this good start at it.

In a standalone boto command I had put together to allow this same thing but using IPython as a shell, I assumed environment credentials and passed in arguments for the account number and IAM role to construct the ARN. Your idea of adding the [Roles] would be good for accounts which you don't have specific credentials. But you could also add the account number to a profile, pass in an assumerole profile/IAM role and construct the ARN.

And I agree that having multiple sessions at the same time in the same shell would be dangerous and cumbersome to add to the commands. However, having different sessions in separate shells would be useful and might require some thought on how to cache the credentials uniquely (perhaps by parent pid?).

[ptone]

This opens a can of worms somewhat, but I think the most sane way to do sessions is to have an interactive sub-shell, like you would have for db CLI tools, where you connect to specific DBs. Keeping a session "open" in the context of just a bash shell seems too risky to me.

Does a session auto-expire?

Why not use the role name, and get the ARN programatically - instead of duplicating that in the config file.

I think the console feature is really nice (but for some reason I couldn’t get it to work, even though other aspects of the session and role were working).

I would love to see the part that generates the console login URL factored out into a call in boto directly - for all kinds of other uses.

I also would make the console a command that takes the role/role ARN directly and launches the console without needing to be wrapped in session start/end calls.

[garnaat]

Thanks @markpeek and @ptone for the comments.

I agree that pinning the session to the shell makes sense. I'm not sure how best to do that. The best I can come up with is os.getppid() and then use the returned process group id when creating the path to the cached session credentials but that doesn't work on Windows. Using os.getpid() does work on Windows but doesn't do us any good since it would be the process id of the CLI command not the parent shell.

The problem with having the user specify a role name and then trying to look it up is that you don't know what account in which to look it up. The role itself has been created in another account and the account you are currently using has been granted access to assume the role. But the role isn't owned by my account.

Sessions do expire but the botocore code managing the sessions takes care of that and automatically renews them.

@ptone - I would love to hear more about your console not working.

As for the sub-shell idea, we did discuss this in the early days of the CLI. It obviously didn't happen and it's up to @jamesls to decide now whether it ever will.

[markpeek]

To your point about not knowing the account to look up. I was implying you do something like this:

[profile dev]
aws_access_key_id=<dev access key>
aws_secret_access_key=<dev secret key>

[profile prod]
aws_access_key_id=<prod access key>
aws_secret_access_key=<prod secret key>
aws_account_id=0123456789

Run it something like this which should allow you to generate the ARN from the account id and role:
aws-cli --profile dev --assume-profile prod --assume-role myiamrole

And in this case you could omit the aws_access_key_id and aws_secret_access_key from the prod profile. But your [Roles] might end up being just as easy and not require as many command line arguments.

[jamesls]

Closing out, superseded by 22932e5