Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Do not import AWS creds from an expired STS token #1322

Closed
wants to merge 1 commit into from

Conversation

46bit
Copy link
Contributor

@46bit 46bit commented Apr 13, 2018

What

See commit message for details.

How to review

Try using this and check it works well.

Who can review

Not @46bit

We have a script `./scripts/create_sts_token.sh` for generating
temporary AWS credentials. It acts as a 2-factor way of logging into
an environment, using permanent AWS credentials and a one-time code.

When creating an STS token we calculate when it will expire. If that
script is re-run it will only create a new STS token if the existing
one has expired. If they have expired it will delete the old file and
then try to create a new one.

However if your shell imports the token file on startup you have a
problem. If your temporary credentials have expired then the script
will delete the file but fail to generate new credentials (because the
STS file has overriden your global credentials.) The way around this
is to then open a second shell after that file has been deleted, but
it's all a mess.

In this commit we change the STS Token files to only import the
environment variables if they have not yet expired. The new behaviour
would be that the renewal script works immediately. Many of us use
wrapper scripts but I still encounter related issues sometimes.
@alext
Copy link
Contributor

alext commented Apr 13, 2018

I'm not sure I understand in what case the token would be stale. This script always calls the delete_stale_tokens function before generating a new token, so the token should never be stale after calling this.

I'm wary of having the generated token files contain more than export statements.

Have you tried instead using this script via a function similar to the one documented here: https://government-paas-team-manual.readthedocs.io/en/latest/team/managing_aws_access/#temporary-credentials

Personally, I use a variation on that pattern with the following function in my .bash_login:

aws_key() {
  if [ -z "${1}" ]; then
    echo "Usage: aws_key <target>" 1>&2
    return 1
  fi
  local target=$1
  export AWS_DEFAULT_REGION=eu-west-1
  export AWS_ACCOUNT=$target
  eval $(pass "gds/aws/${target}")
  "${HOME}/paas/paas-cf/scripts/create_sts_token.sh" && source "${HOME}/.aws_sts_tokens/${AWS_ACCOUNT}.sh"
}

@46bit
Copy link
Contributor Author

46bit commented Apr 13, 2018

I'm not sure I understand in what case the token would be stale. This script always calls the delete_stale_tokens function before generating a new token, so the token should never be stale after calling this.

When I started on PaaS, various constraints meant I was importing source ~/.aws_sts_tokens/dev.sh directly in my .zshrc. The script may delete that file, but if its expired credentials are already loaded into your environment then the aws calls will fail.

It's been bugging me for months what to do about it and I finally had this idea.

@46bit
Copy link
Contributor Author

46bit commented Apr 24, 2018

I'm going to close this, and try to bring the problem up at a Knowledgeshare instead.

@46bit 46bit closed this Apr 24, 2018
@46bit 46bit deleted the improve-sts-token-expiry-experience branch April 24, 2018 16:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants