Securing AWS Credentials on Engineer's Machines | Hacker News Reader

Securing AWS Credentials on Engineer's Machines

99designs.com

15 pointslox3 comments

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?

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.

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.

Reply on news.ycombinator.com