Connecting AWS Organizations to SaaS InsightCloudSec

Once your InsightCloudSec instance is up and running the first thing you'll want to do is begin integrating your AWS organization(s) to take advantage of the security insights that apply to your entire cloud footprint. If you have any issues or questions with this setup, reach out to the support team through the Customer Support Portal.

If you need to add a single account_to the SaaS version of InsightCloudSec, review SaaS AWS Cloud Setup (Single Cloud).

Connection overview

For InsightCloudSec to securely access the information contained within your AWS Organization and its member accounts, you'll need to create and set up some roles, policies, and trust relationships using provided CloudFormation Templates (CFTs). If you're not familiar with this process we recommend that you review AWS' IAM documentation for more information on these concepts.

Prerequisites

Before you configure anything in your AWS environment, you'll need the following:

  • Admin access to your AWS organization and the member accounts you want to harvest
  • The unique Amazon Resource Name (ARN) for your InsightCloudSec instance. Your unique InsightCloudSec ARN will look something like this: arn:aws:iam::123456789123:role/DivvyCloud-CustomerName-Install-Role, with the 12-digit account ID and CustomerName values being replaced with your personal values
    • Contact your Customer Success Manager or the support team through the Customer Support Portal if you do not have this information
  • Organization Admin permissions within InsightCloudSec
  • InsightCloudSec IAM CloudFormation Templates (CFTs) (see below) and the permissions to use & implement CFTs

We recommend that you review the documentation on AWS Additional Configuration, particularly the additional steps to support Opt-in regions.

Value Names (DivvyCloud vs. InsightCloudSec)

Some components use our former product name (DivvyCloud vs. InsightCloudSec). Updates to the naming of these components will be communicated when changes are made, but note that the name difference does not affect setup or functionality within the product.

CloudFormation Templates

Our team maintains the following templates to help automate policy and role setup across your organization management and member accounts:

Service Control Policies - Implementation & Known Issues

Within AWS, a Service Control Policy (SCPs) is a type of policy used to manage permissions at the organization level. Per AWS, "SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs help you to ensure your accounts stay within your organization’s access control guidelines.” Read more from AWS here on using SCPs.

Many organizations choose to implement SCPs for security purposes, while also providing the permissions required for InsightCloudSec to function with full visibility into their AWS accounts.

It is important to note that when implemented, many SCPs will block the required permissions InsightCloudSec needs to operate -- even when permissions have been explicitly granted via roles and policies.

  • If this scenario applies to your environment, you will need to revise your SCP to ensure you have permitted the required InsightCloudSec permissions._
  • This is normal SCP behavior as they are organization-wide policies. SCPs are configured within AWS to supersede other types of permissions.
  • You can review our AWS IAM Policies for details, otherwise refer to the AWS documentation on SCPs.
  • In more limited cases, an SCP in conflict with an existing role/policy can also result in visibility issues.

Warnings with False Positives - Known AWS Service Control Policy Issue

When viewing details on the Clouds Listing page, InsightCloudSec may provide false positive Warnings around missing permissions. In some scenarios the permissions are granted within a Service Control Policy (SCP) but are falsely report as denied.

This scenario is the result of a known issue within AWS where if an Organization has an SCP with conditions based on global keys (for example: aws:PrincipalArn) the IAM Policy Simulator results are not accurate because it does not have context with the global keys.

If you have verified that your resources are being harvested as expected you can safely disregard these warnings.

Setup AWS for InsightCloudSec

Step 1: Generate the External ID

An External ID is generated for your specific InsightCloudSec organization when you initiate the process to add an AWS Organization within InsightCloudSec. The External ID will be the same for every individual cloud account or AWS Organization.

This process obeys AWS best practices and prevents the confused deputy problem from occurring. The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action.

Generate the External ID

  1. Login as an Admin to InsightCloudSec and go to Cloud > Clouds.
  2. On the Organizations tab, click Add Organization.
  3. For Cloud Type, select Amazon Web Services.
  4. Copy the External ID. The External ID is the same for both parts of the form (Organization data and Organization member accounts)/
Step 2: Create a CloudFormation Stack for Organization Data Harvesting

Your AWS cloud account needs a standard harvesting role and policy to ensure proper integration with InsightCloudSec. This requires creating another CloudFormation Stack using the provided Harvest-Role-Member CFT that will configure the account for the additional role and policy.

Create a CloudFormation Stack for Organization Data Harvesting

  1. Login as an Admin to the AWS account you want to harvest and access the CloudFormation service and click Stacks in the left-hand menu.
  2. In the top right corner of the Stacks table, click Create stack > With new resources (standard).
  3. On the Import overview page, click Next.
  4. Specify the Management Account Organization Role CFT URL.
    1. Click Template is ready.
    2. Click Amazon S3 URL.
    3. Input the Harvest Organization Role CFT URL: https://s3.amazonaws.com/get.divvycloud.com/prodserv/divvycloud-deployment-native/aws/cft/iam/DivvyCloud-AWS-IAM-Harvest-Role-Org-CFT.yaml
    4. Click Next.
  5. Specify stack details.
  1. Enter a name for the stack. For example InsightCloudSec-Org-Data-Harvester-Stack
  2. Select Yes to require an external ID to assume the Organization role, then enter the external ID.
  3. Optionally, update the default policy name. For example: InsightCloudSec-Org-ListDesc-Policy
  4. Enter the ARN for your InsightCloudSec instance. The ARN contains your unique AWS account ID and role name.
  5. Click Next.
  6. (Optional) Add tags, and click Next.
  1. Review and create the stack.
  1. Review the stack's configuration to ensure everything is accurate.
  2. Acknowledge the warning about IAM capabilities toward the bottom of the page.
  3. Click Create stack.
  4. Verify the stack is created successfully.
Step 3: Create a CloudFormation Stack for Organization Management Account Harvesting

Your AWS Organization Management account also needs a standard harvesting role and policy to ensure proper integration with InsightCloudSec. This requires creating another CloudFormation Stack using the provided Harvest-Role-Member CFT that will configure the Organization Management account for the additional role and policy

Note: Ensure you're logged into the Organization Management account so the StackSet can be run from there to access all the member accounts you wish to harvest.

Create a CloudFormation Stack for Organization Management Account Harvesting

  1. Login as an Admin to your Organization Management AWS account and access the CloudFormation service and click StackSets in the left-hand menu.
  2. In the top right corner of the Stacks table, click Create StackSet.
  3. Configure the template.
    1. (Optional) Provide an IAM admin role to perform all the operations in the StackSet within your account(s) and adjust the IAM execution role name as necessary.
    2. Click Template is ready.
    3. Click Amazon S3 URL.
    4. Input the Harvest Member Role CFT URL: https://s3.amazonaws.com/get.divvycloud.com/cft/Divvy-CFT-IAM-Harvest-Role-Member.yaml
    5. Click Next.
  4. Specify the StackSet details.
    1. Enter a name for the stack.
    2. Edit the parameters.
      1. For the Harvest role type, select Standard-Managed (read only, AWS managed). Review AWS-Managed Supplemental Policy for more information about this policy.
      2. (Optional) Update the default role and/or policy name. For example: InsightCloudSec-Org-Member-Role
      3. Enter the same ARN you used in the stack for your InsightCloudSec instance in the previous step.
    3. Select Yes to require an external ID to assume the harvesting role, then provide the InsightCloudSec external ID.
    4. Click Next.
    5. (Optional) Add tags, IAM roles, and set additional options.
    6. Click Next.
  5. Review and create the stack.
    1. Review the stack's configuration to ensure everything is accurate.
    2. Acknowledge the warning about IAM capabilities toward the bottom of the page.
    3. Click Create stack.
    4. Verify the stack is created successfully.
Step 4: Create a CloudFormation StackSet for Member Account Harvesting

Setting up proper harvesting of your accounts and their associated resources is straightforward: each account that contains resource data you want to harvest for InsightCloudSec will need access to the same harvesting role (Role ARN, external ID, etc.) with the same policy attached. The relevant CFT for this setup will configure all provided accounts accordingly.

Note: Ensure you're logged into the Organization Management account so the StackSet can be run from there to access all the member accounts you wish to harvest.

Create a CloudFormation StackSet for Member Account Harvesting

  1. Login as an Admin to your Organization Management AWS account and access the CloudFormation service and click StackSets in the left-hand menu.
  2. In the top right corner of the Stacks table, click Create StackSet.
  3. Configure the template.
    1. (Optional) Provide an IAM admin role to perform all the operations in the StackSet within your account(s) and adjust the IAM execution role name as necessary.
    2. Click Template is ready.
    3. Click Amazon S3 URL.
    4. Input the Harvest Member Role CFT URL: https://s3.amazonaws.com/get.divvycloud.com/cft/Divvy-CFT-IAM-Harvest-Role-Member.yaml
    5. Click Next.
  4. Specify the StackSet details.
    1. Enter a name for the stack.
    2. Edit the parameters. The values must match the parameters from the stack created in the previous step.
      1. For the Harvest role type, select Standard-Managed (read only, AWS managed). Review AWS-Managed Supplemental Policy for more information about this policy.
      2. (Optional) Update the default role and/or policy name. For example: InsightCloudSec-Org-Member-Role
      3. Enter the same ARN you used in the stack for your InsightCloudSec instance in the previous step.
    3. Select Yes to require an external ID to assume the harvesting role, then provide the InsightCloudSec external ID.
    4. Click Next.
    5. (Optional) Add tags, IAM roles, and set additional options.
    6. Click Next.
  5. Set deployment options.
    1. Click Deploy new stacks.
    2. Choose to either deploy to accounts or organizational units, then provide a comma-delimited list of accounts or organizational units (or upload a CSV file).
    3. Select us-east-1 to deploy the stack. Note: Currently only single-region role deployment is supported.
    4. Click Next.
  6. Review and create the stack.
    1. Review the StackSet's configuration to ensure everything is accurate.
    2. Acknowledge the warning about IAM capabilities toward the bottom of the page.
    3. Click Create Submit.
    4. Verify the StackSet is created successfully.

Configuring InsightCloudSec

Now that the AWS Organization and relevant member accounts have been configured for harvesting, it's time to enable harvesting within InsightCloudSec.

Prerequisites

Before you can successfully add an Organization to InsightCloudSec, you will need the following on hand:

  • The ARN for the organization harvesting role
  • The ARN for the standard harvesting role

Configure InsightCloudSec

  1. Open the InsightCloudSec platform to the in-progress cloud account setup page.
  2. Provide a nickname for the Organization. This creates a system Badge containing the nickname that can be searched or referenced throughout InsightCloudSec.
    Adding a Cloud Organization will replace the credentials of associated cloud accounts already in InsightCloudSec. Misconfiguration of the roles in member accounts will result in gaps in visibility.
  3. Provide credentials for harvesting Organization data.
    1. Provide the Role ARN for the Organization Management Account role. For example: arn:aw:iam::123456789012:role/InsightCloudSec-Org-ListDesc-Role
    2. Provide a session name and duration. The session name will display in any CloudTrail logs and is useful for auditing purposes.
  4. Provide credentials for harvesting Organization member accounts data.
    1. Provide the Role ARN suffix for the standard harvesting role. For example: InsightCloudSec-Org-Member-Role
    2. Provide a session name and duration. This will display in any CloudTrail logs and is useful for auditing purposes.
  5. Configure the optional badging and scope-limiting settings.
    • Provide one or more prefixes to match accounts against. Any accounts with names that match those prefixes will be excluded.
    • to automatically remove suspended AWS accounts from InsightCloudSec, select Auto-remove suspended accounts. When enabled, a background process begins running and removes the accounts automatically as they're found.
    • To allow InsightCloudSec to automatically badge your incoming accounts based on AWS account tags, select Auto-Badge Accounts.
    • To only include nested accounts and OUs associated with a given ID (or set of IDs), select Limit Import Scope and provide Organizational Unit ID(s).
  6. When you've completed all of the fields and details outlined above, click Add.

After successful submission a background job is enqueued that will fetch and synchronize all of your accounts. Depending on the number of accounts this will take a few minutes. In this example walkthrough, 127 accounts took a little over 1 minute.

Expected Validation

When the form is submitted the form values are validated for formatting correctness. Next we test the Organization Management Role for the following and will reject submission if any of the following fail.

  • Attempt to perform AssumeRole operation with Instance Role credentials.
  • Test role permissions with iam:SimulatePrincipalPolicy to verify we can perform all necessary Organization harvesting. We test the policy for all actions documented above in the "Organization Management Role" section.

The member account roles are not validated at this point. Validation of member accounts is done during the syncing process and any failures are reflected in the Cloud account status on the Cloud Listing page.

Editing Organization Credentials

To make changes to any part of the credential configuration requires a complete resubmission of all fields due to all fields being encrypted in storage.

Filtering options can be updated independently by leaving all credential fields blank. If blank the existing credential configuration is left as is.

From the Organizations page, click the link for the number of accounts. This will redirect you to the Cloud Listing page filtered by the Cloud Organization using a badge associated with all member accounts.

Errors in permissions or failure to assume a role are represented by the cloud status.

Post-Setup Information

Congratulations on integrating your AWS Organization with InsightCloudSec. Below you'll find some key information about your new integration as well as managing it.

Badging of Accounts

Accounts added via an AWS Organization will have a few Badges automatically associated to them:

  • cloud_org_path: shows the location of the account in the Organization tree
  • All tags associated with accounts are added as badges

Despite not being listed explicitly, the system.cloud_organization:<cloud_org_id> badge is associated with all accounts in an Organization.

Changes to Credential Management

Because all accounts within the AWS Organization use the same credential configuration, they are considered as "managed" by the organization. This is reflected on the cloud settings page where the option to edit credentials and delete the account are not available.

Auto-badging

As an enhancement to support for provider-base organizations InsightCloudSec includes auto badging capabilities. The purpose of auto-badging is to create a 1:1 map of AWS account-level tags to Badges in InsightCloudSec. This allows Clouds to be scoped to a badge that maps to the account tag.

After the tags and labels are harvested into InsightCloudSec as badges - you cannot delete them in InsightCloudSec - they must be deleted in AWS and the changes will propagate to InsightCloudSec.

Auto-badging takes place in two stages.

StageDescription
Retrieves tags and labels from each account and project and compares them with ResourceTags associate with the cloud account in the InsightCloudSec database.If there are any changes detected, the ResourceTags in the database are overwritten with the values from the account/project.

This means that Cloud Account tags should not be locally modified since any local changes will be overwritten the next time the process runs. Additionally, any local changes that are made to Cloud Account tags are not pushed back up to the cloud provider.
Retrieves all ResourceTags from the local database that are associated with the accounts managed by an organization.For each cloud the list of tags for that cloud is compared with the current list of Badges and for each Key/Value pair of tags:

  • Existing Badges with a Key prefix of system. are skipped.
  • If the corresponding Badge with the Key/Value pair for that cloud does not already exist, it is created.
  • If a tag Value changes, the Badge with the corresponding Key will be updated to that value.
  • If a Badge no longer has a tag with a corresponding Key, it will be deleted.
  • All Badges that have a corresponding tag will have their autogenerated column set to ‘true’ even if they were previously set to ‘false’.