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.
Yeah, 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.)
> 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.
Visual 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.)
Whether 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.
Any advice/tutorials on how to set this up? Ideally I'd like just that ssh session to change the text to red for prod boxes but then go back to my normal iTerm theme after exit...
Any links to how to do this? My google-fu seems to be failing me. I'm assuming you somehow set things up so it automatically detects the page / content (based on the environment name or instance tags??) and changes the background?
One way to do this is to look at the "awsc-login-display-name-account" div, which contains your account ID. You can then alter the look of the page (perhaps making the top header bright red) depending on which account ID is in use.
By 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.
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.
> You can assign multiple IAM roles to an instance profile, which is what is associated with an instance.
Perhaps there is some contradiction in the IAM docs, but I couldn't find that reference. This seems to indicate that only one role can be assigned to an instance profile:
"Note that only one role can be assigned to an Amazon EC2 at a time, and all applications on the instance share the same role and permissions." (first paragraph, last sentence)
Have 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...)
Separate 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.
Hey 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.
