Applying Least Privilege Policies Automatically Using CloudFormation

A cross-account role allows you to share resources across AWS accounts. Since your cross-account role works globally, you don't need IAM users to sign in and out of accounts to access these resources.

The CloudFormation template is an alternative to creating a cross-account role manually. It is a JSON file pre-configured with all the parameters and provisions you need to access your AWS resources across multiple accounts in your cloud environment. This template allows AWS to standardize permissions across your deployment automatically.

To create a cross-account role using the CloudFormation template, follow this workflow.


Workflow

Perform the following steps in the AWS Management Console:

  1. Log in to the AWS Management Console.
  2. From the menu bar, right-click your account name, and select My Billing Dashboard from the fly-out menu.

    The Billing & Cost Management Dashboard opens.

  3. From the dashboard, click Billing Preferences.

    The Preferences page opens.

  4. Verify that the Receive Billing Alerts checkbox is selected. (optional)

Perform the following steps in CloudCheckr:

  1. Launch CloudCheckr.
  2. Select your account from the Accounts List page. If you have not created a CloudCheckr account, go to the Create an Account in CloudCheckr topic.
  3. From the left navigation pane, select Account Settings > AWS Credentials.

    The Credentials page opens.

    The Use a Role for Cross-Account Access tab displays and provides instructions how to use CloudFormation to create your role.
  4. Click the Launch CloudFormation Stack link.

    This action opens the Quick Create stack wizard in AWS.

Now that you have access to the Quick Create stack wizard, you can configure your stack.

CloudFormation associates your stack with the template URL that contains all the necessary parameters and provisions:

  1. Under the Stack name section, type a name for your stack.
    Keep the stack name as short as possible; it gets appended to the Role ARN value later and that value cannot exceed 64 characters.
  2. Scroll down to the Parameters section.

    CloudFormation autopopulates the CloudCheckr Account and CloudCheckr External ID with the values associated with your AWS account.

  3. Under Account Type, leave the default setting, Standard, since you are creating a cross-account role for a commercial account.
  4. In the Inventory section, select True from the InventoryAndUtilization drop-down menu if you want your stack to include Inventory permissions.
  5. In the Billing section:
    1. select True from the CostPermissions drop-down menu to include the Cost and Billing permissions in your stack
    2. type the name of your S3 bucket in the BillingBucket field only if you are using the Detailed Billing Report (DBR) as your primary billing method
    3. type the name of your S3 bucket in the CurBucket field if you are using the Cost and Usage Report (CUR) as your primary billing method

      In this example, we configured a stack that will have Cost and Billing permissions and have access to the CUR bucket, since it is our primary and preferred billing method:

  6. In the Security section:
    1. select True from the from the Security drop-down menu to include the Security and CloudTrail permissions in your stack
    2. type the name of the S3 bucket where AWS stores your CloudTrail data

      In this example, we configured a stack that will have Security permissions and have access to a selected CloudTrail bucket:

  7. From the CloudWatchFlowLogs drop-down menu, select True to include the CloudWatch Flow Logs permissions in your stack.
  8. Scroll down to the Capabilities section, select the I Acknowledge that AWS CloudFormation might create IAM resources check box, and click Create stack.

    The next screen displays your stack status, which changes from CREATE_IN_PROGRESS to CREATE_COMPLETE once AWS finishes creating the stack.
  9. Click Resources.
  10. Click the Physical ID link for the IAM role.
  11. Locate the Role ARN value at the top of the Summary page and click the Copy icon.

Perform the following steps in CloudCheckr:

  1. Return to the Credentials page in CloudCheckr.
  2. Paste the Role ARN value in the AWS Role ARN field.
  3. Click Update.

    You now have a cross-account role that will allow you to access the resources in other AWS accounts based your selected permissions.

    If you are performing this step as part of your initial account preparation, continue to the next step: Enable Tags for Cost Report.

Policy Structure Notes

Click each button to review the exceptions to our default policy structure.

CloudCheckr will attempt to ingest data from all of the AWS core features to populate the Cost, Billing, Security, Inventory, and CloudWatch Flow Log reports. Since CloudCheckr must make calls even to those categories where you have not enabled permissions, you will see Unauthorized Access attempts in your CloudTrail logs. These logs are only an indication of the CloudCheckr workflow and in no way reflect an attempt on the part of CloudCheckr to collect unauthorized information from customers.
To help you maintain a secure, least privilege configuration, CloudCheckr's Security/Compliance policy does not include any s3:GetObject permissions. However, you can add add the s3:GetObject permission to the following reports:
  • S3 Encryption Details report: enables CloudCheckr scan your encrypted S3 buckets.

    We recommend restricting this permission to only selected S3 bucket(s).

  • List of VPCs report: enables CloudCheckr to ingest data from the Elastic Beanstalk applications for this report.

    The default Security/Compliance policy will only display 0 as the number of Elastic Beanstalk applications within a VPC.

As per the latest AWS requirements, CloudCheckr's CloudFormation template and the Inventory policy do not include the s3:GetEncryptionConfiguration by default.

However, without this permission, CloudCheckr cannot get the information it needs to report on the S3 Bucket Without Default Encryption Enabled Best Practice Check (BPC). If you decide not to add this permission to your policy, we recommend that you ignore or disable this BPC to avoid any false negatives.

How did we do?