AWS Cloud Account Onboarding: Assuming an ARN Role as a Linked or Master Account

Learn how to onboard an AWS cloud account by assuming an Amazon Resource Name (ARN) role and give CoreStack authorized access to that account.

Suggest Edits

Overview

There are certain settings and prerequisites that need to be configured in your AWS account before it can be fully onboarded into CoreStack. Primarily, this involves creating an Identity Access Management (IAM) Role for CoreStack and providing it with the necessary permissions.

There are two ways users can authorize CoreStack to access their AWS cloud accounts:

  1. Assume an Amazon Resource Name (ARN) role
  2. Provide access through a secret key

In this user guide we'll cover the first approach. To learn about the second approach, please refer to this user guide.

Onboard AWS account by assuming ARN role

The first method of providing CoreStack with access to your AWS cloud account involves using a CloudFormation template. It will take care of creating an IAM Role for CoreStack and assign the required permissions automatically.

When onboarding a new cloud account in CoreStack, the associated AWS IAM role must be created with one of the following access permissions:

  • For Assessment: Read-Only Access
  • For Assessment & AWS Sync: Read-Only + AWS Sync Access
  • For Assessment + Governance: Read-Write Access (Permission for Assessment, AWS Sync & Remediation)

CoreStack simplifies this process by providing a CloudFormation Template that will take care of creating an IAM Role and assigning the necessary permissions automatically within your AWS cloud environment.

Based on the type of access you wish to provide for CoreStack, you can use one of the AWS S3 storage bucket URLs provided below to get the appropriate preconfigured CloudFormation template.

  1. S3 URL with Template for Assessment Only (Read-Only Access)
  2. S3 URL with Template for Assessment + Automation (Read-Write Access)
  3. S3 URL with Template for Assessment (Read-Only + Sync with AWS WAF)

The minimum permissions required for running any of these templates are shown below, both in the image preview and bullet list following:

  • IAMFullAccess
  • AmazonSNSFullAccess
  • AWSCloudFormationFullAccess
  • IAMAcessAnalyzerFullAccess

📘

Note to remember:

Ensure that the policy (CoreStack_SelfservicePolicy) under IAM/Policies and the role (CorestackConfigRole) under IAM/Roles are deleted before executing any of the templates more than once.

How to delete the ‘CorestackConfigRole’ role

To delete the CorestackConfigRole role in AWS, follow the below steps:

  1. Go to IAM > Role in the AWS web portal.

  1. Search for “CorestackConfigRole”.

  1. Select the role once it appears, then click on Delete. It will ask for confirmation.

How to delete the ‘CoreStack_SelfservicePolicy’ policy

To delete the Corestack_SelfservicePolicy policy in AWS, follow the below steps:

  1. Go to IAM > Policies in the AWS web portal.

  1. Search for “CoreStack_SelfservicePolicy”.

  1. Select the policy once it appears, then click on Action. You’ll see an option for Delete – click it.

  1. It will ask for confirmation – proceed by clicking on Delete.

  1. If done correctly, you should see a message confirming the policy was deleted successfully.

How to run the CloudFormation template in AWS

To run the CloudFormation template in AWS after downloading one from the links above, first log in to your AWS portal and navigate to:

CloudFormation > Stacks > Create stack

Click on “Create stack.” Then follow the steps below.

  1. Specify the template: Paste the S3 URL from above pointing to your chosen CloudFormation template to create a user that can access your AWS Account from CoreStack.

  1. Specify stack details: Enter the following details for the stack…
  • Stack name (Provide any name based on your requirements)
  • External ID (Can be any word or number you and the third-party account agree on)
  • Role name (Provide any name based on your requirements)

📘

Note:

The External ID is a unique ID created for each CoreStack customer. Hence to get the ID for your account, please reach out to [email protected]

The support channel is available 24/7 and you can typically expect a response within 2 hours.

🚧

For the “Assessment + Automation (Read-Write Access)” option:

In the Create Stack section, make sure to set ‘IncludeBudgetPolicy,’ ‘IncludeGuardrailPolicy,’ and ‘IncludeInspectoryPolicy’ to True.

If these are set to False, some other features might not work.

  1. Configure stack options: Leave these fields blank and proceed.

  1. Review the details, then check the acknowledgement box shown in the image below before finally clicking on Create stack when you’re ready.
  • “I acknowledge that AWS CloudFormation might create IAM resources with custom names.”

After the stack has been created, it will be visible when you go to the CloudFormation > Stack list area in your AWS cloud portal.

  1. Click on the newly created stack, then go to the output and copy the below details. You will need these details later when onboarding the AWS cloud account into CoreStack.
  • Role ARN: The Amazon Resource Name (ARN) for the new IAM Role.
  • External ID: The external ID can be any word or number that is agreed upon between you and the third-party account.
  • Require MFA: Enable this option to indicate whether the role is restricted with multi-factor authentication (MFA)

After running the template of your choice, a new role will be created with all the necessary permissions. Again, no manual intervention is needed.

Permissions created after the template runs

Here are the permissions that will be assigned to the role that is created based on which CloudFormation template you choose to use:

For S3 URL with Template for Assessment Only (Read-Only Access):

Permissions (Read-only)
ce:GetReservationPurchaseRecommendation
ce:GetReservationUtilization
support:DescribeTrustedAdvisorCheckResult
budgets:ViewBudget
config:
Lambda:

For S3 URL with Template for Assessment + Automation (Read-Write Access):

Permissions (Read and write)
ec2"ec2:DetachVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeregisterImage",
"ec2:TerminateInstances",
"ec2:CreateTags",
"ec2:CreateImage",
"ec2:RunInstances",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:AllocateAddress",
"ec2:CreateVolume",
"ec2:RevokeSecurityGroupIngress",
"ec2:DeleteVolume",
"ec2:DescribeVolumes",
"ec2:CreateSecurityGroup",
"ec2:DeleteSecurityGroup",
"ec2:CreateSnapshot",
"ec2:ModifyInstanceAttribute",
"ec2:AssociateAddress"
"iam:SimulatePrincipalPolicy","organizations:ListAccounts",
"s3:HeadBucket",
ec2:DescribeSubnets"
s3"s3:CreateBucket",
"s3:HeadBucket",
"s3:DeleteObject",
"s3:DeleteBucket",
"s3:GetBucketLocation",
"s3:GetBucketTagging",
"s3:GetObject",
"s3:ListObjects",
"s3:PutBucketPolicy",
"s3:PutBucketTagging",
"s3:PutEncryptionConfiguration"
CloudTrail"cloudtrail:AddTags",
"cloudtrail:CreateTrail",
"cloudtrail:DeleteTrail",
"cloudtrail:DescribeTrails",
"cloudtrail:GetTrailStatus",
"cloudtrail:ListTags",
"cloudtrail:PutEventSelectors",
"cloudtrail:StartLogging",
"cloudtrail:UpdateTrail"
IAM"iam:CreateRole",
"iam:DeleteRole",
"iam:GetRole",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:DeleteRolePolicy",
"iam:PutRolePolicy",
"iam:PassRole"
computeoptimizercompute-optimizer:*
Cloudwatch"cloudwatch:DescribeAlarms",
"cloudwatch:DeleteAlarms",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics",
"cloudwatch:PutMetricAlarm"
ElasticComputeCloud"ec2:StartInstances",
"ec2:StopInstances"
Inspector"inspector:ListRulesPackages",
"inspector:DescribeRulesPackages",
"inspector:ListAssessmentRuns",
"inspector:ListAssessmentTemplates",
"inspector:ListFindings",
"inspector:DescribeFindings",
"inspector:DescribeAssessmentRuns",
"inspector:CreateResourceGroup",
"inspector:CreateAssessmentTarget",
"inspector:CreateAssessmentTemplate",
"inspector:StartAssessmentRun"
cfn"cloudformation:CreateStack",
"cloudformation:DeleteStack",
"cloudformation:DescribeStackResource",
"cloudformation:DescribeStacks",
"cloudformation:UpdateStack"
GuardDuty"s3:*",
"guardduty:GetFindings",
"guardduty:ListDetectors",
"guardduty:CreateDetector",
"guardduty:UpdateDetector",
"s3:ListBucket",
"guardduty:DeleteDetector",
"guardduty:CreatePublishingDestination",
"guardduty:DeletePublishingDestination",
"guardduty:DescribePublishingDestination",
"guardduty:ListFindings",
"guardduty:GetDetector",
"guardduty:TagResource",
"iam:TagRole",
"iam:CreateServiceLinkedRole"
kms"kms:Create",
"kms:Describe",
"kms:Enable",
"kms:List",
"kms:Put",
"kms:Update",
"kms:Revoke",
"kms:Disable",
"kms:Get",
"kms:Delete",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
Auth"aws-portal:ViewBilling",
"aws-portal:ModifyBilling",
"budgets:ViewBudget",
"budgets:ModifyBudget",
"budgets:CreateBudgetAction",
"budgets:DeleteBudgetAction",
"budgets:UpdateBudgetAction",
"tag:getResources",
"tag:getTagKeys",
"tag:getTagValues"

"ce:GetReservationPurchaseRecommendation",
"ce:GetReservationUtilization",
"support:DescribeTrustedAdvisorCheckResult"
workspaces"workspaces:TerminateWorkspaces",
"workspaces:RevokeIpRules",
"workspaces:Describe",
"workspaces:ListAvailableManagementCidrRanges",
"workspaces:DeleteIpGroup",
"workspaces:DeleteWorkspaceImage",
"workspaces:StopWorkspaces",
"workspaces:StartWorkspaces",
"workspaces:Create",
"workspaces:RebootWorkspaces",
"workspaces:Modify*",
"workspaces:UpdateRulesOfIpGroup",
"workspaces:DisassociateIpGroups",
"workspaces:RebuildWorkspaces",
"workspaces:AssociateIpGroups",
"workspaces:AuthorizeIpRules",
"workspaces:ImportWorkspaceImage",
"workspaces:DeleteTags"
Lambda"lambda:*"
DynamoDB"dynamodb:DescribeTable",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchGet",
"dynamodb:DescribeStream",
"dynamodb:DescribeTable",
"dynamodb:Get",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchWrite",
"dynamodb:CreateTable",
"dynamodb:Delete",
"dynamodb:Update*",
"dynamodb:PutItem"
Wellarchitected"wellarchitected:*"
Configconfig:*

📘

Note:

Apart from the aforementioned permissions, a role should also be created for trusted authentication with CoreStack that should have the following services and polices as well.

Services
"lambda.amazonaws.com",
"config.amazonaws.com"
Policies
"logs:*"
"s3:*""cloudtrail:",
"cloudwatch:",
"config:",
"lambda:",
Managedpolicyarns
"arn:aws:iam::aws:policy/ReadOnlyAccess"
"arn:aws:iam::aws:policy/service-role/AWS_ConfigRole"
Policy
"iam:PassRole" to be given s for the role created for CoreStack

For S3 URL with Template for Assessment read only + WAF:

Permissions (Read-Only + Assessment, with AWS sync)
ce:GetReservationPurchaseRecommendation
ce:GetReservationUtilization
support:DescribeTrustedAdvisorCheckResult
budgets:ViewBudget
config:
lambda:
Wellarchitected:*

Onboard your AWS cloud account by assuming a role as a Linked Account

To proceed with onboarding your AWS cloud account into CoreStack using the Assume Role method for an AWS Linked Account, please follow these steps.

  1. First, navigate to the Account Governance dashboard view in CoreStack and click on Add New.

  1. Select AWS, and click on Get Started.

  1. Select the Linked Account option under Account Type, then select your AWS Environment preference (Standard vs. Gov Cloud), then choose Assume Role under Authentication Protocol.

  1. Fill in the details saved earlier from the AWS console outputs:
    • Role ARN: The Amazon Resource Name (ARN) of IAM Role.
    • External ID: The external ID can be any word or number that is agreed upon between you and the third-party account.
    • Require MFA: Enable this to indicate if the role is restricted with multi-factor authentication (MFA).

After some time, the details will be validated and the account will be added in CoreStack.

Onboard your AWS cloud account by assuming a role as a Master Account

To proceed with onboarding your AWS cloud account into CoreStack using the Assume Role method for an AWS Master Account, please follow these steps.

  1. First, navigate to the Account Governance dashboard view in CoreStack and click on Add New.

  1. Select AWS, and click on Get Started.

  1. Select the Master Account option under Account Type, then select your AWS Environment preference (Standard vs. Gov Cloud), then choose Assume Role under Authentication Protocol.

  1. Fill in the details saved earlier from the AWS console outputs:
  • Role ARN: The Amazon Resource Name (ARN) of IAM Role.
  • External ID: The external ID can be any word or number that is agreed upon between you and the third-party account.
  • Require MFA: Enable this to indicate if the role is restricted with multi-factor authentication (MFA).
  • Bucket Name: Specify the S3 Bucket name that is configured in your account to get the
    detailed billing data.
  • Cost Report Format: Select whichever option works best for you.

  1. After some time, the details will be validated and the account will be added in CoreStack.

Next steps

Now that you understand how to create the necessary roles and permissions in your AWS environment to onboard your AWS cloud account into CoreStack, as well as how to onboard your AWS cloud account(s) by assuming an ARN role using either a Linked or Master AWS account, you can proceed to the post-onboarding configurations.

Browse the links available in the next steps below to choose where to go next.

Updated 9 months ago

What’s Next