Hacker News new | ask | show | jobs
by ryanfitz 4189 days ago
For working with AWS apis, securing access keys, and granting least privilege, the first step to take is to make completely separate AWS accounts per environment. Make a Bigco-Prod, Bigco-Test, Bigco-Dev AWS accounts. Developers only access the Development account, so even if they connect with a highly privileged key / role and a bug wipes out your services, only the Dev account is effected and production keeps on humming. AWS makes this extremely easy to do, they offer consolidated billing to pay one bill for multiple accounts. Takes no more than 30 min to set this all up and I would recommend this for even a company with just 1 developer.
4 comments

The difficult part of separate AWS accounts is that connecting between them is tricky (Security Groups, VPC, etc.). Not impossible, but a pain to get right. The spectrum between dev and prod isn't so clear-cut for a business with petabytes of data: you often want to develop systems against production data (read-only, of course), and having two copies of the data can be prohibitively expensive. Of course, with the appropriate access policies you can share the data safely, but then what about that IRC server that was non-production but then wound up part of the deployment flow and became mission-critical?
I'm still not sure why it has taken so long for IAM to support this kind of configuration, using VPC as the isolation point.

Our use case is running packer[0], which requires a large IAM profile[1], without needing to create a separate account for AMI creation. It would be awesome to issue credentials that limited Security Group creation/deletion, Instance Creation/Termination, etc to a single, VPC.

[0]: https://www.packer.io/ [1]: https://www.packer.io/docs/builders/amazon.html

Why not just build using packer's chroot support? No instance creation or security groups and much faster.
I wish AWS made it possible to move reserved instances between accounts. We have reserved instances for our test environment that are in the same account as our production instances, and I'd need to sell them from one account at a loss and repurchase them in the other account.
That is definitely a very good practice. Still it does not eliminate the need for something like Hologram, since you still need to take care of your keys (both for security reasons) and to make sure your dev env is as close as possible to your production and ...
Didn't mean to imply no need for Hologram or not to keep dev as close as possible to production. However, I do think you should be doing this before looking into a solution like hologram. I've seen many startups that run all their environments on a single account and eventually something bad happens knocking production offline. If you were to use hologram, but still only a single AWS account you could still just as easily kill production.
Absolutely, I've seen similar things. Even after explaining the pitfalls some people are reluctant to do it. Partly because people don't want to embrace the aws ("cloud", the new way of doing things) completely, they still want to think of everything as if it is their own machines in their own data server only amazon plays the role of the ops guys.