Force new session option about aws-vault HOT 19 CLOSED

from aws-vault.

We use Terraform for infrastructure provisioning. Some deployments / modifications are known to take a long time. For example Elastic Search or RDS modifications. These can take up to 20 minutes to complete. Expiration of AWS credentials half way through can be pretty bad as the Terraform state file will become out of sync with reality.

from aws-vault.

from aws-vault.

Interesting, I missed that in the documentation. If I understand correctly the fake IAM server runs on localhost and reissues temporary credentials when requested? If so that would be a problem for our setup. We use MFA. Also i'd prefer temporary credentials not be available to whoever has access to the laptop without re-authenticating.

from aws-vault.

i would like to have this feature. if someone has an idea where this should go into the code i would like to try to implement it

from aws-vault.

@chbiel what are you trying to achieve?

from aws-vault.

we have the same problem as @coen-hyde .
we are enforced to use mfa with a session timout of 1h. it happens regularly that the session ends during a aws-vault exec run with terraform and we have to clean up the account after such "crash".
i would like to have e.g. a commandline option like "--renew-mfa" that deletes the session and forces me to reenter my mfa credentials.

another cool thing we be to have something like:
"your sessions end in xx minutes! do you want to refresh? y/n"
and to make it configurable when this should be displayed, e.g. when the session ends in less than 30 minutes.

i hope the use case got clear :)

from aws-vault.

@chbiel you can now increase the session up to 12h.
that should help.
running with --server would also request MFA (at least does on Mac)

adding an extra command to aws-vault will not help in anyway here.
it is as simple as re-running the command and it will reauth

from aws-vault.

badly i am not allowed to change the session timeout (big company, central it, etc...)

The problem is that there is no easy way to find out, how long my session is open and when the timeout will be reached.
i already found a workaround by using: aws-vault remove -s to delete my session and force a revreationg of the session

from aws-vault.

aws-vault exec <PROFILE> --session-ttl=8h --assume-role-ttl=1h -- MY_COMAND.sh
should already give you at least 1h for the MFA

from aws-vault.

i'm confused why you need to remove the session.
just rerunning your last command will reset the mfa

from aws-vault.

The problem does not occure when the mfa token is already expired.
The problem occures when the token is about to expire, e.g. in 5 minuten but I run a Terraform command that takes 10 minuten.
In this case the Terraform apply crashes and the whole account is messed up and you have to clear it up by hand because the token is not renewed during the Terraform apply.

So I want to ensure that the token expires in more that 10 minuten before I run the 10 minute Terraform apply. For that I currently have to delete the current active session that lasts 5 minutes to have a new session that lasts 1 hours

from aws-vault.

i'm not sure what you are saying.
i never had TF get corrupted... it might fail to push the state, but you can push manually or on the next apply run
have you tried --server ?
works well for us.

from aws-vault.

hmm i will have a look again if this would solve the problem.
it may is specific for the setup. we use remote s3 state with dynamodb lock.
when the token expires during an apply the lock does not get removed and no state gets pushed.

so now, when you remove the lock from dynamodb and run apply terraform will tell you that there are many thing in the actual account different to what he expect from his state.

i am not sure if a state push is secure enough so you can ensure that everything on aws is exactly as terraform wrote it into it's local / not pushed state.

from aws-vault.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from aws-vault.

Please re-open, I'm working on a PR for this.

from aws-vault.

The problems here seem to describe needing creds that are good for a minimum amount of time rather than to force a new session.

This could be achieved simply by a --min-duration or similar that offsets the remaining time available by the min duration required, that is considered the cached creds expired if (cached seconds remaining - min duration seconds) < 0.

from aws-vault.

--duration was added in v5 which I think addresses this issue

from aws-vault.

I have proposed adding a --min-duration in #612 to force refresh of --server credentials with an expiration below a threshold.

However, I now have a babysitter process that watches time remaining in an MFA session. I do not want any time period of invalid credentials, so the babysitter process sleeps and attempts to refresh the MFA credentials when there is less than a few minutes left. However, exec will not refresh credentials with time remaining.

So I an option to exec to force credential refresh. I'll take a look at the proposed code change in #474 and test against the 6.x beta to see if it still works.

from aws-vault.