AWS Organizations - Setting Up and Configuring User Accounts

Setting Up Organizations on AWS Account

AWS Orgnizations provides you with an efficient way to better manage and organize your AWS accounts. You can create sub-accounts under your root account and invite existing AWS accounts to join your organization. Joining an organization account enables Consolidated Billing and better Access Management through Switch Role functionality.

Here’s what you can do with AWS Organizations:

  • Create Organization
  • You can organize Organizations into Organization Units
  • You can invite an existing account
  • Enable root users to access child accounts using one set of credentials

For this, you have to:

  • Use generic names and emails for root accounts
  • Create the role with which the administrative user in root account can access the child account
  • From now on, create users in root account and let them switch role

Granting User Permissions to Access Resources

Though not compulsory, it’s recommended to create users only under the Root Account. By granting AssumeRole permissions to the users, you can allow them to assume certain roles in the child accounts.

  • Create all Users in the root account
  • Create role in each account with Principal of the parent account
  • Give permissions to the users to assume the relevant role in the child account
  • Create a role in the child accout which will allow Principal of the root account to access it
  • Define the permissions allowed in the created Role within the Child Account

Accessing Cross-Account Resources using AWS CLI

#/.aws/config:
[profile developer.development]
role_arn = arn:aws:iam::[Child-Account-ID]:role/[roleName]
source_profile = [account-profile]

Example

In this example we would like to create accounts with the following structure and grant users the correct permissions to each account.

AWS Accounts:

1. Creating AWS Accounts Hierarchy under Organization

While creating child accounts, AWS will by default create role named as OrganizationAccountAccessRole. This role created in the Child Account, will allow trusted entity being Root Account an AdministratorAccess to the Child Account. Meanwhile from the Root Account we can restrict who of our users is allowed to AssumeRole in the Child Account.

Trusted Entities of OrganizationAccountAccessRole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::[AWS-Root-Account-ID]:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Following the same Analogy, we can create several roles in the Child Account with different permissions to the Resources in the child account. Then we can control which users from the Root Accountcan AssumeRole for which Role in the Child Account, defining User’s Cross-Account Resource permissions.

2. Create Users and Groups in the Root Account

Groups:

  • Developers
  • DevOps
  • Testers
  • Marketing

Allow Developers to assume “Developer” role in any of the Children Accounts. Add the following policy to the “Developers” group:

Developer Group Policy

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::*:role/Developer"
  }
}

[profile developer.it-test-aws] role_arn = arn:aws:iam::257040594755:role/Developer source_profile = sac

Do the same for DevOps, Testers or any other groups.

DevOps Group Policy

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::*:role/DevOps"
  }
}

Tester Group Policy

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::*:role/Tester"
  }
}

Marketing Group Policy

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::*:role/Marketing"
  }
}

3. Managing Root Account User Permissions in the Child Account

At this stage, user of the Root Account can assume a role in the Child Account, using the “AssumeRole” permission granted in the policy above.

Now it’s time to create these roles and grant permissions by assigning Policies to them. Each Child account in the current example will have the following roles:

  • Developer
  • DevOps
  • Tester
  • Marketing

Each of these roles will have the following Trusted Entities, based on what Root Account users can AssumeRole from the Child Account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::[AWS-Root-Account-ID]:root"
      },
      "Action": "sts:AssumeRole",
    }
  ]
}

4. Accessing Child Account resources using AWSCLI

In order to access Child Account using the CLI, we need to configure a new profile for the AWS CLI where we would specify the assumed role and the source account credentials from the root account.

# ~/.aws/config
[profile root-account-profile]
region = eu-west-1
output = json
[profile developer.child-account-1]
role_arn = arn:aws:iam::[Child-Account-Id]:role/Developer
source_profile = root-account-profile

# ~/.aws/credentials
[root-account-profile]
aws_access_key_id = [ROOT-Account-Key-Id]
aws_secret_access_key =  [ROOT-Account-Secret-Key]

Publish Date: 2019-11-24