Use different AWS accounts (per stage)

[davetapley]

Hi, firstly amazing work, thanks for open sourcing it! 😎

Early on in the README the Concepts section states:

This module allows practical isolation / compartmentalization of privileges within a single AWS account along the following axes:

It's a known practice to separate stages in to different AWS accounts, e.g:

• From the Serverless docs

  As an advanced use-case, you can deploy different stages to different accounts by using different profiles per stage.

• From a top Google result:

  Most companies don’t keep their production infrastructure in the same account as their development infrastructure. This helps reduce any cases where developers accidentally edit/delete production resources.

---

It'd be great if you could indicate in the README:

1. Why you decided to implement a single AWS account solution here, and:
2. Whether there are plans (or willingness to accept work on) adding support for using different AWS accounts (per stage).

[ryan-roemer]

Hi!,

We have a lot more discussion of the potential privilege infrastructures (incl multiple accounts) at: https://formidable.com/blog/2019/locking-down-aws-serverless-applications-the-right-way/ . (I should probably link that blog post to the README 😄 )

For different account isolation, I think it should straight up "just work" as long as the Terraform stack is provisioned from the appropriate different account. For the core module and all submodules, we have an input iam_account_id that defaults to the "calling AWS account" that then locks down all permissions to that account.

I haven't done a ton with cross-account AWS infrastructures, so perhaps you can fill me in on the needed scenario (e.g., one account provisions resources for a different account, etc.). And we do have that iam_account_id input that may get us most/all the way there already. At any rate, just let me know and maybe post some sanitized tf configs and I'll see what we can do.

[teemuvesala]

This is not working as it currently is at the multi account environment. I've attached you an example about multi-account setup and its AWS Organization structure. All IAM users are at "Account account" (I'm bad to invent good names). To access to any other environment they have to assume the cross account role. Staging & production environments should not be touched by human. In practice access to them is temporary. Also the CI pipeline has very limited access to production accounts. If CI pipeline is hacked, it should not cause any destruction to the production.

To make these better to suite with multi account is to use cross account roles instead of groups. Of course they need also the information about the "Account account" to allow the cross account role assume.

In multi account environment Group is to describe what roles the person can assume. (It also enforces e.g. MFA usage) Group itself doesn't give much access directly. Only one who doesn't have to assume the role is the root account of master account. And it should be locked so that nobody is using it regularly.

[ryan-roemer]

@teemuvesala -- Can you explain more what needs to change in this module? I'm unclear on that part.

E.g., are you saying in addition to attaching permissions to groups (named here): https://github.com/FormidableLabs/terraform-aws-serverless/blob/master/variables.tf#L101-L104 we should also create new roles that match each of these admin|developer|ci groups so that they can be attached?