search

Bridgewater / holochrome

Use your IAM role (from instance metadata) to open the AWS console
https://chrome.google.com/webstore/detail/holochrome/fgnplojdffjfbcmoldcfdoikldnogjpa
MIT License
104 stars 9 forks source link

Session Duration #8

Closed walterking closed 8 years ago

walterking commented 8 years ago

Just announced, the session duration param goes up to twelve hours now. How do you feel about increasing it? https://blogs.aws.amazon.com/security/post/Tx3GL3IZE3FIGB6/Enable-Your-Federated-Users-to-Work-in-the-AWS-Management-Console-for-up-to-12-H

ryansydnor commented 8 years ago

Awesome! I'll get to this ASAP.

ryansydnor commented 8 years ago

So, I thought this would be easy... but it's not. There are definitely intricacies to the SessionDuration parameter. When I add it to my HTTP request I get:

400: Invalid Credentials Parameter. The request sent by the client was syntactically incorrect.

My guess is that I cannot ask for a longer session duration from a "child" set of credentials when my "parent" (from Hologram) is using the default. Unfortunately, I don't have high confidence in my theory due to the fact I was unable to ask for a session < 1 hr either. Plus, their documentation states:

Call the AWS federation endpoint and supply the temporary security credentials to request a sign-in token. If you used one of the AssumeRole* APIs to get the temporary security credentials, then this request to the AWS federation endpoint can include the HTTP parameter SessionDuration to specify how long the federated consoled session is valid, up to a maximum of 12 hours.

I've opened a support ticket to see what's going on. I'll keep this ticket updated with the results.

ryansydnor commented 8 years ago

In fact, the sample code provided by them does not work!

ryansydnor commented 8 years ago

Unfortunately, this will occasionally error out depending on how the environment is set up. Due to this inconsistency, I don't feel comfortable adding the parameter at the moment.

From Amazon:

So it appears the problem is when you have an IAM role assuming another IAM role to get the temporary credentials. I have talked to the service team and they confirmed you can't set SessionDuration when the temporary credentials are retrieved by an IAM role against another IAM role. The documentation will be updated to reflect this detail, as at the moment it is not very clear. So basically you need an IAM user with long term credentials to make the STS AssumeRole API call to get the temporary credentials from the IAM role, then use the returned temporary credentials to build the SignIn URL.

I suppose we could attempt to intelligently retry upon receiving a 400 for that particular call. Do you think that'd be worthwhile?

walterking commented 8 years ago

it makes sense, otherwise you could just keep granting yourself credentials indefinitely. i dont think we(adroll) would use long term keys just to get around this, so id lean towards not doing it.

im not sure you could even make it work, because hologram returns role credentials anyway

On Mon, Aug 1, 2016 at 8:34 PM, Ryan Sydnor notifications@github.com wrote:

Unfortunately, this will occasionally error out depending on how the environment is set up. Due to this inconsistency, I don't feel comfortable adding the parameter at the moment.

From Amazon:

So it appears the problem is when you have an IAM role assuming another IAM role to get the temporary credentials. I have talked to the service team and they confirmed you can't set SessionDuration when the temporary credentials are retrieved by an IAM role against another IAM role. The documentation will be updated to reflect this detail, as at the moment it is not very clear. So basically you need an IAM user with long term credentials to make the STS AssumeRole API call to get the temporary credentials from the IAM role, then use the returned temporary credentials to build the SignIn URL.

I suppose we could attempt to intelligently retry upon receiving a 400 for that particular call. Do you think that'd be worthwhile?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Bridgewater/holochrome/issues/8#issuecomment-236785848, or mute the thread https://github.com/notifications/unsubscribe-auth/AAev1RDs8CUGVNosP_EF3rWlZ0zZVQn9ks5qbrrEgaJpZM4JXyW2 .

ryansydnor commented 8 years ago

It makes a lot of sense why they'd do this.

We're not planning on doing anything with long-lived keys either.

Too bad, this was exciting :|

Closing.