4 ms·

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

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.

colemorrison 10y ago
This is good stuff right here. Separate accounts can do tons. Also helps prevent stuff like dealing with VPC collision overhead.
- availabilly 10y ago
  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.
  - joseph 10y ago
    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.
    - schlarpc 10y ago
      AWS uses this isolation pattern internally for just about everything, for what it's worth.
      - openasocket 10y ago
        Not the "per region" part, that just seems silly.
      - joseph 10y ago
        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.
ecesena 10y ago
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.
- joshpadnick 10y ago
  We (http://gruntwork.io 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-in-the-aws-management-console-cross-account-access/ https://aws.amazon.com/blogs/security/enable-a-new-feature-i...
  - colemorrison 10y ago
    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.
lostcolony 10y ago
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.
vacri 10y ago
> 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.
mooreds 10y ago
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/ https://aws.amazon.com/organizations/ It allows you to manage accounts via an API.

colemorrison 10y ago

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

availabilly 10y ago
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.
- joseph 10y ago
  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.
  - schlarpc 10y ago
    AWS uses this isolation pattern internally for just about everything, for what it's worth.
    - openasocket 10y ago
      Not the "per region" part, that just seems silly.
    - joseph 10y ago
      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.

ecesena 10y ago

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.

joshpadnick 10y ago
We (http://gruntwork.io 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-in-the-aws-management-console-cross-account-access/ https://aws.amazon.com/blogs/security/enable-a-new-feature-i...
- colemorrison 10y ago
  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.

lostcolony 10y ago

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.

vacri 10y ago

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

mooreds 10y ago

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/ https://aws.amazon.com/organizations/ It allows you to manage accounts via an API.