search

Nike-Inc / gimme-aws-creds

A CLI that utilizes Okta IdP via SAML to acquire temporary AWS credentials
Apache License 2.0
925 stars 263 forks source link

Access Keys are saved in cleartext #184

Open adamipv opened 4 years ago

adamipv commented 4 years ago

Currently the Access Key and Secret Access Key are saved under ~/.aws/config in clear text

Expected Behavior

The config file should be encrypted

Current Behavior

The config file is cleartext, containing sensitive information

Possible Solution

https://hackernoon.com/aws-credentials-stored-safer-m5673wd3

Sector95 commented 4 years ago

The credentials generated by this tool are temporary, which was part of the attraction to the STS pattern (1 hour lifetime). Seeing as how they are so short lived, it doesn't seem like we're mitigating a very large risk by encrypting the credential file.

Let me noodle this for a bit, we might be able to make this an optional function, but making it easy to use for the consumers of the tool might be challenging.

elijah-roberts commented 4 years ago

@adamipv We partially reduced this risk by updating the file permissions to 0600 which gives access to only the file owner. https://github.com/Nike-Inc/gimme-aws-creds/pull/181

I agree with @Sector95 that because these are temporary credentials, in addition to the fact that the file permissions are restricted, there is a very narrow risk of exposure.

Looking at the article this looks like something that could easily be used in a standalone script to encrypt after running gimme-aws-creds. i.e gimme-aws-creds && encrypt. I like the unix philosophy of having a program do one thing, and one thing well. i.e retrieve credentials from okta. shrug

What do you think @adamipv and @Sector95 ?

ChristophShyper commented 4 years ago

@adamipv file is controlled by AWS CLI, so it should be addressed to them.

You can mitigate it with using environment variables and not writing tokens to credentials file - write_aws_creds and output_format in gimme-aws-creds's config.