5 ms·
For Tarsnap, I have several completely independent AWS accounts. This is partly because I needed privilege separation before IAM existed; but I keep this setup
by cperciva 11y ago
For Tarsnap, I have several completely independent AWS accounts. This is partly because I needed privilege separation before IAM existed; but I keep this setup mainly because it's dead simple and completely avoids the risk of user error: When I'm doing development work, I don't even have access to the Tarsnap production accounts.
- gargarplex 11y agoGenius insight that could be applied to not just AWS but Parse, etc.
- ksikka 11y agoHey gargarplex - on the off chance that you see this, could you send me an email? Wanted to get in touch with you regarding one-to-many supplier registration. I've saved it in the about section of my user page. Apologies in advance for the unrelated comment.
- eropple 11y agoYeah, this is the way to go. For when I have to use the AWS console, I use separate Chrome profiles for each of my environments, so I don't even have cookies, saved passwords, etc. that might relate to other accounts. (I also use separate Chrome themes in each environment and use a CSS manipulator such that my prod console is in a bright-freaking-red Chrome window with a red background. Blue for test, green for dev.) For my own AWS accounts, I use a read-only account in the profile and, on the very rare occasion I want to get clicky rather than use awscli to frob something, I'll log out and log back in as my writable-to-IAM user. I have a third user that only has IAM read/write privileges if I have to deal with that service. (I haven't sold my clients on this approach, though.)
- icelancer 11y ago> use a CSS manipulator such that my prod console is in a bright-freaking-red Chrome window with a red background. Blue for test, green for dev Ha, I do the same thing. I learned about this from a previous job I had where prod/test webapps were functionally similar but had obnoxious coloring in the header. Very effective.
- eropple 11y agoVisual indications are so great, aren't they? I do it with terminals, too; prod servers get obnoxious red-background prompts. (Root terms on all my machines look different from unprivileged ones, too.)
- icelancer 11y agoHmm good idea. I haven't had any issue with it but it's trivial to change background colors. Probably not a bad idea. Thanks for the tip!
- tabio 11y agoWow, I can't remember the last time I ran a shell directly on a prod machine. The very thought feels so dirty now.
- zaroth 11y agoWhether it's shell literally, or "shell" as in, the window from which you ultimately perform shell-like things, there's still a place you perform these tasks and knowing when you are in simulation or actual is an important state to track.
- eropple 11y agoWhen you inherit your environment and are whipping it into shape, shit happens.
- ossreality 11y agoI don't know which emotion is stronger, knowing that you haves sooooo much config that is inherently different across your environments... is it empathy? sadness? frustration? exasperation <- probably exasperation. I'm exasperated by the amount that people try to assert this over and over. Bullshit. Learn to test better. Learn ther term "integration environment", better, if you think you know it.
- jebblue 11y ago
- sandworm101 11y agoFyi (and don't take this as legal advice) such separation is a really good idea in terms of PII/PCI compliance.
- tomphoolery 11y agoHave you ever thought of separating your dev and production environments into VPCs? That's what we do at my job and it works out very well for us. Though of course, you're line of work involves much more data security than mine. The main takeaway here is to always use IAM accounts when doing stuff with AWS, and make sure each IAM account is only permitted to do the things you want it to do. It might be a pain in the ass to learn how the IAM policy syntax works, but believe me it works out for you in the long run! (And, of course, use multi-factor auth. But you should be doing that anyway...)
- cperciva 11y agoSeparate VPCs wouldn't help in terms of AWS keys. I don't just want to keep dev and production servers separate; I want to keep the AWS services which they access (e.g., S3) separate too.
- objectivefs 11y agoBy using IAM roles for EC2 you can also move more of the key management to Amazon. When you attach an IAM role to an EC2 instance Amazon will provide temporary credentials through the local metadata server and automatically rotate them for you. This avoids storing and copying your credentials, and makes it easy to separate your environments.
- cperciva 11y agoIAM roles for EC2 terrify me. They completely break OS privilege separation, since every user has access to the keys.
- jamiesonbecker 11y agoIAM instance profiles are dangerous. Let's say you have a bug or SQL injection in a web app (or choose any server): the user running the web app and/or database now has access to your AWS account. Instance profiles are available to every user and process on the server for the life of the server. Layering multiple least-privilege roles is impossible: you can't assign multiple IAM roles to an instance. You can't separate what process receives access to those credentials. The old-school way of embedding credentials in a config file and make it readable only by root and/or a specific user account on the system is currently the best solution. Better, but more challenging at scale, are SE-Linux, AppArmor, etc.