Aws-vault: `eb-cli` credentials override aws-vault profile

[emhoracek]

Started using aws-vault today and was following some instructions that had already worked for a coworker. aws-vault exec profile-name -- (command to create keypair) works fine. I am happy. I go on to to run commands to create an Elastic Beanstalk app and environment with the same profile. I look in the account -- no app! But the commands ran successfully. With a sinking feeling, I start looking through the other accounts I have access to, and finally find the app I just made in a seemingly arbitrary (client!) account. Oddly, the keypair I created before the Beanstalk app is the correct account. I used the same aws-vault exec profile-name prefix for all three commands. What?!

Finally I noticed in my credentials file I have a credential for eb-cli which seems to be the profile that is used if you don't specify a profile with eb commands. After deleting that credential and rerunning the eb command using aws-vault exec profile-name, the app was created in the correct account.

Not sure this is a bug, but you may want to note in the README that this can happen.

[FernandoMiguel]

That's your cli tool that stupidly saves the STS token to file.
I've seen other apps do that, and it's a terrible security practice.
I can't offer a solution.
You could use an hammer and touch the file with a different user preventing
it from being updated with the wrong cached creds

--
Fernando Miguel

On Wed, 29 Aug 2018, 18:57 Libby, [e-mail] wrote:

Started using aws-vault today and was following some instructions that had
already worked for a coworker. aws-vault exec profile-name -- (command to
create keypair) works fine. I am happy. I go on to to run commands to
create an Elastic Beanstalk app and environment with the same profile. I
look in the account -- no app! But the commands ran successfully. With a
sinking feeling, I start looking through the other accounts I have access
to, and finally find the app I just made in a seemingly arbitrary (client!)
account. Oddly, the keypair I created before the Beanstalk app is the
correct account. I used the same aws-vault exec profile-name prefix for
all three commands. What?!

Finally I noticed in my credentials file I have a credential for eb-cli
which seems to be the profile that is used if you don't specify a profile
with eb commands. After deleting that credential and rerunning the eb
command using aws-vault exec profile-name, the app was created in the
correct account.

Not sure this is a bug, but you may want to note in the README that this
can happen.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/99designs/aws-vault/issues/280, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKRrnbAMNXyfy4SaqaRVfYcvw9DgXlhks5uVsfegaJpZM4WR829
.

[mtibben]

I do recall hearing about this eb weirdness before. The docs at https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-configuration.html indicate that AWS_EB_PROFILE can be used to specify a profile directly. I'd be interested if that works?

[emhoracek]

I think I see now what happened. When I ran aws-vault exec profile_name -- eb init [etc], I didn't specify a profile, so it used eb-cli in the .elasticbeanstalk/config.yml file. That's why the eb-cli profile in $HOME/.aws/credentials was used in that and subsequent commands, overriding aws-vault. So, I think as long as users specify a profile with --profile, they shouldn't run into this problem. I think I didn't understand how aws-cli worked, and I assumed eb would magically know the profile.

[lox]

So, I think as long as users specify a profile with --profile, they shouldn't run into this problem.

Do you mean --profile to eb-cli? Even if you give aws-vault a profile, the subprocess won't have one set in the environment. You'll need to specifically give eb-cli a profile of default for it to work with aws-vault.

[lox]

I actually kind of like the idea of making ~/.aws/credentials unwriteable.

[FernandoMiguel]

The number of times I had to go debug devs issues and find out they had a
credentials file, is astounding

--
Fernando Miguel

On Fri, 31 Aug 2018, 00:08 Lachlan Donald, [e-mail] wrote:

I actually kind of like the idea of making ~/.aws/credentials unwriteable.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/99designs/aws-vault/issues/280#issuecomment-417483042,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKRrkDwgXilyRH8jP3I9pgs2kLa5RJWks5uWGJJgaJpZM4WR829
.

[lox]

Perhaps we should show a warning in aws-vault if that file exists? There are very few scenarios where it will be intended.

[FernandoMiguel]

I never thought of that, and now I love that idea.

I would even consider a more radical approach, and ask the user if they
wish to destroy the file during aws-vault add
But I do understand that would be a dangerous move.

--
Fernando Miguel

On Fri, 31 Aug 2018, 03:30 Lachlan Donald, [e-mail] wrote:

Perhaps we should show a warning in aws-vault if that file exists? There
are very few scenarios where it will be intended.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/99designs/aws-vault/issues/280#issuecomment-417520687,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKRrigHT_zDtgQEbHjsnY8ha1YeLGKqks5uWJHBgaJpZM4WR829
.

[lox]

I've always wanted an aws-vault import that could import credentials, but that is another story :)

[emhoracek]

Perhaps we should show a warning in aws-vault if that file exists? There are very few scenarios where it will be intended.

@lox I also like this idea. Basically all I wanted out of this issue personally was an assurance that other ignorant users in my position in the future will be warned. :joy:

[lox]

Noted, and this will remain a shining beacon for future eb-cli users. Beware ye who enter here!

[stale[bot]]

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.