1
votes

I want to separate out AWS resources for a multi-tenanted SaaS into separate accounts under an AWS Organization.

  • I have multiple OUs, split by function, e.g. logs, audit, compute. I will have SCPs associated with each OU.
  • Each tenant will have an account under each OU, which means as I add new tenants, each account will inherit the respective SCP to that OU.

To enable the developers to build out the platform and to be able to debug the running system, I want to use a hub-and-spoke type approach to access control using a federated IdP, similar to that described here: https://segment.com/blog/secure-access-to-100-aws-accounts/.

Specifically, I will have an identity account that will be bound to Okta. Users will authenticate into this account and then use sts:assume-role to escalate to roles in other accounts. Note that I want a separate identity account and not have users authenticate to the master account in the organization (thus within the organization, we have master and identity accounts, plus the OUs each with their respective accounts).

In order to programmatically create a new tenant, I need to create the tenant's accounts and place them in the correct OU, and therefore this needs to be done in the master account. I can do this by creating a role within the master account and having developers assume that role from the identity account.

How do I create roles in the new accounts that developers can assume from the identity account? Member accounts have a role called OrganizationAccountAccessRole automatically created (see here for details), but that is set to only be accessible from the master account and it enables access to everything in that account. How can I enable a developer within the identity account to programmatically create new accounts and the roles within them without granting such all-powerful permissions (they should have no more permissions to perform this task than necessary). I don't think I can assume a role in the master account from the identity account and then further assume a role in a third account?

EDIT: I am really only interested in answers that address the steps/configuration needed to achieve the solution I describe.

2

2 Answers

1
votes

Cloudformation StackSets addresses this problem.

Basically, the steps are:

  1. Set up roles in the child accounts that have permissions to deploy resource with a trust relationship to the role of the parent account (which you're deploying from)

  2. Create a StackSet in parent account and deploy a Cloudformation template into it to selected accounts or Organizational Units (OU) or whole organization

StackSets supports AWS Organizations so you can select OU's instead of selecting individual accounts.

1
votes

I would put forward that an elegant solution is to use the AWS Service Catalog product which allows you to create and manage catalogs of services that are approved for use in your AWS environment. As a matter of fact, the setup described in this AWS blog post can be customized to achieve what you want. It provides an example for creating an Account Builder product that when launched by your end users, uses an AWS Lambda script to:

  1. Provision an AWS member account
  2. Assume the Organizational Role for the account
  3. Use a CloudFormation template to customize the account (in your case, to create the additional IAM roles)

You can customize it further to even delete the Organizational Role account when it's done.

Source code for the Lambda function along with the CloudFormation templates is provided that you can tweak to produce the exact behavior you are looking for.

Hope this helps.