
Securing AWS Credentials on Engineer's Machines - lox
https://99designs.com/tech-blog/blog/2015/10/26/aws-vault/
======
conorgil145
I recall seeing a post about a month ago directly to the GitHub repo for this
tool. Since then, I have started working on a similar effort to address the
issue of API credentials on developer machines. I looked into using STS too,
but the issue I kept coming back to was that if a malicious third party (MTP)
obtains the developer's machine and it is turned on and logged in (ie, ignore
HDD encryption and assume they got the credential somehow), then the MTP can
use the same workflow as the engineer to obtain access to the production
system, right?

I suppose we need to clearly define the attack vector that we are trying to
prevent. If we define the attack vector to be a MTP using developer
credentials to obtain access to the production environment for any amount of
time, then does aws-vault address that use-case?

If the long lived credentials on the developer box only have permission to
request short lived creds from STS which have greater permissions, then I
understand how that is certainly better than the MTP having long lived creds
with greater permissions. But, how much better is it really? If the creds have
IAM permissions, then the MTP could use the temporary creds to lock everyone
else out except the root account.

I suppose the article is trying to make the point that the short lived
credentials need to have appropriate permissions for the task which the
developer needs to complete on a regular basis? Even so, someone somewhere
needs to have creds which can modify IAM so that we can manage users, right?

I feel like I am talking myself into a rabbit hole here. Can anyone pull me
out? I think/hope that I am missing something obvious and I'm hoping that the
answer is "we're not solving everything, but we are reducing the attack
surface".

Thoughts?

~~~
lox
Author of post and aws-vault tool here. There is absolutely a short window of
time when it's possible to steal an unlocked machine and have full access to
the unlocked keychain. The same issue exists for Keychain itself and things
like ssh-agent. The idea is to reduce the attack surface, as you said, and to
practice principle of lease privilege. Create roles for specific use cases
with just the required permissions, and assume them as needed, based on
credentials stored encrypted at rest. It's doesn't solve everything, but it's
considerably better than the alternatives

AWS offers the concept of Power Users, which have access to everything except
IAM. We use them for most things, which mitigates the risk of an attacker
escalating temporary access into long term access. They can still cause a lot
of damage, but it's time limited.

------
wolfeidau
Great work on this, it really is a weak spot for a lot of aws developers,
myself included.

I would love to see more work on the AWS side to address this with integration
to keychain, 1password and the like.

