Hacker News Reader

Comment by joshpadnick | Hacker News Reader

I work on multiple AWS installations and we use the approach you describe of only defining IAM Policies and avoiding resource-based policies where possible. The one exception is KMS Keys, which require a KMS Key Policy.

That being said, I've found IAM's power impressive but ultimately complex. If you're really serious about isolating users from certain resources, separate AWS accounts for each environment may well be the best way to do this. This way, you can grant "admin" access to users in your "stage" AWS account, they get all the permissions they need to do their work, and have no permissions to the more sensitive "prod" account.

View on HN

> I've found IAM's power impressive but ultimately complex

Honestly, as a not-a-security-guy, I can count on the fingers of one hand the number of times I've had to learn something around security and it's been easy.

> separate AWS accounts for each environment may well be the best way to do this

A thousand times yes. There is so much to do in IAM, that it's just easier to let the devs have access to a 'test' account, and keep the 'prod' account out of their mitts.

That's what we've done, and it's been a huge help. There are a few areas where it's a little complex (things like build servers; does each environment get its own? That makes it so we have to duplicate effort on the build server rather than knowing it really -is- the same build. But if it's shared across environments, it has -accounts- across all environments. So tradeoffs). But in general shooting for isolated environments has definitely been of benefit.

If the multi account pattern with its higher level of isolation suits your organizational needs, this new AWS offering may be helpful: https://aws.amazon.com/organizations/

It allows you to manage accounts via an API.

Out of curiosity, do you keep 1-1 mapping among users/groups/roles(/resources?) across different accounts? Because that's another possible source of complexity.

We (http://gruntwork.io) are still establishing best practices around managing multiple AWS accounts, but so far having a single "admin" account where all IAM Users are managed seems like a best practice. You can then implement a nifty dropdown that allows IAM Users to easily switch accounts. [1] I'm not sure about how IAM Groups fits into this.

For IAM Roles, we use Infrastructure-as-Code (Terraform) to create all those anyway, so I still prefer to create those in the AWS account that contains the resources to which they apply.

[1] https://aws.amazon.com/blogs/security/enable-a-new-feature-i...

Just for anyone wondering, as per joshpadnick's great suggestions, you can specify other AWS account's users/roles via Principal in a policy as well. Just use the other AWS account in the ARN. edit: if you want to do so via policies that is

I'd be interested to see your team's workflow for multiple accounts @joshpadnick.

This is good stuff right here. Separate accounts can do tons. Also helps prevent stuff like dealing with VPC collision overhead.

One account per service per region per deployment stage (e.g. dev, test, production) is the best practice. How you define "service" is up to you, but I usually divide them by trust/dependency footprints.

This significantly reduces the risk that an account-level problem or throttle will disrupt your entire business.

Fortunately, AWS finally seems to be getting serious about building management tools for multiple accounts. AWS Organizations is way better than the old consolidated billing stuff.

Who calls that a best practice? If you're a very small company, that might be fine. With thousands of employees and tens or hundreds of applications, you'll run into serious problems if you want to use e.g. VPC peering for shared services. You'll also run into major cost issues if for example you have per-VPC or per-account commercial appliances.

AWS uses this isolation pattern internally for just about everything, for what it's worth.

Not the "per region" part, that just seems silly.

That's interesting, because their consultants discourage it for their customers. For companies that want to keep most of their traffic internal, I don't think it's a working model. I suppose Amazon's internally used services are the same ones they expose to customers, so it probably works fine.

Reply on news.ycombinator.com