Hacker News Reader

Comment by cperciva | Hacker News Reader

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.

View on HN

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.)

Wow, I can't remember the last time I ran a shell directly on a prod machine. The very thought feels so dirty now.

When you inherit your environment and are whipping it into shape, shit happens.

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.

How do you know what's really going on on those machines and in their respective environments assuming they are geographically distinct?

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...

In the .bashrc/.zshrc of the remote machine add this:

    echo '\033]11;#440000\007'

On the local machine add this to reset the terminal color:

    ssh () {/usr/bin/ssh "$@"; echo '\033]11;#000000\007'}

You can muck around with your bashrc, if you use that shell.

Hmm 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!

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?

Easy way to do this in e.g. Rails:

  <body style="foo bar baz env-#{Rails.environment}">

Then use CSS like you would normally on body.env-production, body.env-development, etc.

You meant class, not style. But great tip though:

      <body class="foo bar baz env-#{Rails.environment}">

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.

Could make a nice Chrome extension...

You can use an extension like Greasemonkey, with a simple script which will extract aws account id and will apply some css based on it.

I log into different Chrome profiles that style the same pages differently. Dumb and easy.

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.

IAM roles for EC2 terrify me. They completely break OS privilege separation, since every user has access to the keys.

The servers I have set up this way aren't really multiuser machines, but your point is a good one.

Not necessarily; both windows and linux allow firewall rules based on user.

IAM 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.

> Layering multiple least-privilege roles is impossible: you can't assign multiple IAM roles to an instance.

You can assign multiple IAM roles to an instance profile, which is what is associated with an instance.

See e.g. [0]; you can add IAM roles to instance profiles without destroying the instance.

[0] https://docs.aws.amazon.com/cli/latest/reference/iam/add-rol...

> 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)

http://docs.aws.amazon.com/IAM/latest/UserGuide/roles-usingr...

Fyi (and don't take this as legal advice) such separation is a really good idea in terms of PII/PCI compliance.

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.

Genius insight that could be applied to not just AWS but Parse, etc.

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.

Reply on news.ycombinator.com