Using a single AWS account is a serious risk

For Tarsnap, I have several <i>completely independent</i> AWS accounts. This is partly because I needed privilege separation before IAM existed; but I keep this setup mainly because it&#x27;s dead simple and completely avoids the risk of user error: When I&#x27;m doing development work, I don&#x27;t even have access to the Tarsnap production accounts.

About three weeks ago I started working on a new open source project meant to interact with AWS. Coding fast and dumb, I cut and pasted my personal AWS credentials into my source code, committed it, and pushed it to Github.<p>The next day I got an email from Amazon, alerting me to the problem. Apparently, they scrape github looking for just that kind of stupidity. I instantly deleted the project, but it was too late.<p>Amazon ended up waving the nearly $3k in EC2 charges I incurred, thankfully. I&#x27;m now a zealous advocate for making sure a person never even HAS AWS credentials. Instead, make a new user without a password for each use case, and manually select the privileges that account has.<p>If you have a password to AWS, you shouldn&#x27;t have credentials.

&quot;If someone gets access to your AWS access credentials, you’re in trouble.&quot;<p>I know we&#x27;re not supposed to post negative comments that don&#x27;t &quot;add value&quot; to a discussion, but the only thing that comes to mind is &quot;really?&quot;. Your setup is as secure as you make it. How you use your API access is up to you. Putting all your eggs in one basket is not insecure. This article doesn&#x27;t actually bring to light anything important. There is no risk involved so long as you pay attention to what you are doing.<p>Any set of credentials, if leaked, destroys security. So... don&#x27;t set yourself up to leak your credentials? I mean, come on, seriously?<p>*edit: I unfairly used the word &quot;incompetent&quot;. Change to a phrase about paying attention to what you are doing.

&#x2F;&#x2F;Somewhat off topic<p>Using any kind of AWS account (in a personal capacity) is a serious risk in my eyes.<p>Its much like I&#x27;m happy to take the risk of buying shares, but don&#x27;t like leveraged derivatives.<p>I don&#x27;t want to deal with something that is not my area of expertise and has very real potential to blow up in my face.<p>I wish Amazon allowed me to cap spending to say 200USD...that I can plan for much easier than X thousands.

Another risk consideration is that anyone getting unauthorized access to your AWS account can delete all your resources and all your backups (snapshots, etc), effectively putting you out of business. [1]<p>One solution is to backup to a separate backup-only AWS account, with super-serious access controls (MFA and password physically locked away somewhere). Set up a &quot;write-only&quot; link, such that backups can be added, but never removed. This way, in the worst case, your runtime infrastructure can be decimated, but your data backups would be safe.<p>1 - <a href="http:&#x2F;&#x2F;arstechnica.com&#x2F;security&#x2F;2014&#x2F;06&#x2F;aws-console-breach-leads-to-demise-of-service-with-proven-backup-plan&#x2F;" rel="nofollow">http:&#x2F;&#x2F;arstechnica.com&#x2F;security&#x2F;2014&#x2F;06&#x2F;aws-console-breach-l...</a>

At Zalando we have an account per team, and have been releasing a bunch of tooling to help do this securely.[1] It&#x27;s not completely easy (e.g., account creation at Amazon can not be automated), but the security aspects are really nice, and it lets us give teams more or less full access to just their account.<p>[1] <a href="https:&#x2F;&#x2F;stups.io" rel="nofollow">https:&#x2F;&#x2F;stups.io</a>

The MFA Condition is a huge win, and I&#x27;m surprised Amazon hasn&#x27;t built this a tool to make this easier yet.<p>However, I question the merit of using two separate AWS accounts. While this separation of responsibility sounds nice in theory, doesn&#x27;t it introduce additional maintenance burden because you now have two accounts to administer? You can&#x27;t define or manage the roles in the 2nd account without credentials to do so.

I think the comment about using temporary credentials is an interesting one.<p>Where I work, we have a federated access system that generates temporary credentials so you can access the Console without having to sign in, and it uses our work authentication mechanism to do the initial handshake.<p>The thing is this process is useless if you want to use it with the AWS command line client, or any other tools that rely on the use of credentials. It would be nice if AWS adopted a plugin system or something where you could plug in a &quot;credentials provider&quot; of some sort, and the command line client queries that for credentials each time you make a request, instead of having to stash keys in ~&#x2F;.aws&#x2F;credentials

Is there a good primer on AWS and what it provides?

Is there an easier to use UI for setting up IAM users. I get hopelessly confused every time I attempt it, and worry about losing access to services I&#x27;ve already set up.

I like the approach that Google cloud takes with projects. Projects are independent and isolated under a single account.

What&#x27;s cool is that in AWS as a developer they disable the ability to even login with username and password. You can set it up such that the only access is through a site that grants federated access.

Like the solution via MFA &amp; temp credentials! Simple &amp; elegant.

You can also use ssh forwarding to log into your servers through the SSH bastion without dropping your private keys everywhere on the bastion itself, securing access even further.

I seriously question any business running just on AWS. There are plenty of other services that &quot;look like&quot; AWS and give you complete isolation.

aye aye captain obvious!