Session duration as a parameter?

[allquixotic]

Hi, we'd like to be able to specify the maximum session duration of the LinkCallerRole and PermissionSetCallerRole in the parameters (env.yaml). The 1 hour default session expiration makes it difficult to even demo the APIs because of the effort it takes to setup Postman after getting a session token.

We'd probably keep it at a reasonably lower level once we have full automation and have implemented an automated consumer of the APIs, but for dev/test, the 1 hour session duration is very challenging to work with.

Despite IaC best practices, I've manually hacked the max session duration to 12 hours on the roles for now. I'm thinking cross-account-role.ts can be modified where the new Role constructor is invoked, to bring in a parameter from the configuration to optionally edit the session duration.

[leelalagudu]

Hi @allquixotic ,

Thank you very much for your continued support and feedback. We did consider this as a configuration parameter earlier, but did not go through for the following reason:

• Our rationale was that a customer would always assume both LinkCallerRole and PermissionSetCallerRole through another IAM role and generate the STS credentials required. This would therefore mean they would be role chaining and therefore be limited to a maximum of 1 hour session duration for the STS credentials generated.
• Specifying a higher session duration would only be useful when the customer updates the trust policies of LinkCallerRole and PermissionSetCallerRole so that they could assume the role directly rather than go through role chaining.

Is your preference to assume the caller roles directly rather than role chaining? If so, I can extend the configuration parameters with the caveat that this would only be applicable in case of direct role assuming.

Let me know if this fits in with your requirements and I will go ahead with the PR.

Thank you, Leela

[allquixotic]

Hi,

I am indeed accessing the caller roles through another IAM role, using sts assume-role. The API key I use to perform the assume-role is a temporary session (I've manually set the Permission Set to 12h) that I get through AWS SSO - figured I might as well use the feature that the end-users will be saddled with once this is rolled out.

So with the role and the permission set both manually having their session expiration set to 12 hours, I can successfully request a 12 hour credential set from aws sts assume-role.

Every time I do this, I have to:

1. Log out of Okta
2. Log into Okta
3. Go to the AWS SSO chiclet
4. Select the OrgMain account and click Console access
5. Copy the API key, access key and secret access key to ~/.aws/credentials on the EC2 box I use for SSOEx dev/bootstrapping; these are valid for 12 hours
6. Use aws sts assume-role to get credentials for the caller roles; these are also valid for 12 hours now that I've manually set it up that way
7. Copy the six fields (2 x access key, secret access key and session token) into the Postman environment

Only then can I finally issue API requests in Postman. If I had to do this every hour, I would go slightly insane. As it stands, it's a daily chore.

I'm a lazy sysadmin; that's why I went into a job in the DevOps field :) As you can imagine, I would prefer to automate this repetitive workflow. If you have any suggestions on that or best practices, I would appreciate it.

I'll leave it to your discretion to decide whether it makes sense to add the session duration as a parameter based on my input here. I don't want to dictate how your product should work. It just seems to be useful in my use case.

Thanks for working on this!

[leelalagudu]

I think you've convinced us with your 7 step workflow there @allquixotic :) :) ..

As it would be a config driven parameter and not a huge change, we will go ahead with including this ability. I will update here once the PR is merged.

And, thank you once again for all the helpful feedback.

[leelalagudu]

Hi @allquixotic ,

I was looking into this in more detail to include the change as part of the PR and I think I misunderstood the ask earlier.

6. Use `aws sts assume-role` to get credentials for the caller roles; these are also valid for 12 hours now that I've manually set it up that way

Can you confirm if the credentials you are vending in this step are valid for 12 hours?

• Reason for asking this -> After you've executed step 5, you would have already assumed a role. So, step (6) in your sequence is considered by AWS IAM as [role chaining](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html) and this would automatically introduce an upper limit of 1 hour on the credentials validity.

• So, even if we pass a session duration parameter as part of role creation in the code, this would have no effect for step (6) above.

• Could you please confirm if my understanding here is correct (or) if I am missing something here?

• Assuming we both are on the same page, would this alternative help ease this process:

  Creating a utility script that would read environment variables, automatically vend STS credentials, generate your PostMan environment file that you could then manually import into PostMan. So, your hourly refresh would then mean running this script and then importing the environment file into PostMan.

[allquixotic]

I made an error in the above. After hitting the 1 hour role chaining limit with the SSO based sign-on, I used my personal IAM account into the OrgMain account, and get the credentials based off of that. So I'm not using role chaining in practice. That's why increasing the session expiration in the role actually does help me. :)

[leelalagudu]

Aah, that explains my confusion then.

• We will extend the configuration interface to take in 2 additional values for session duration settings of both the roles and set that as part of role creation.
• Along with this change, we will introduce doc updates to call out that this session duration scenario is only valid in an IAM user access scenario.

Does this approach work for you?

[allquixotic]

This works for me! Thank you. :)

[leelalagudu]

@jmejco to investigate and validate if this falls under the role chaining limitation (i.e. 1 hour duration) / if a configurable session time out can be provided.