AWS Cloud Operations Blog

Service Notice – Upcoming changes required for AWS Config

On July 5, 2022, the AWS managed policy AWSConfigRole will be deprecated. This policy is being replaced by a more scoped-down policy, AWS_ConfigRole. The AWSConfigRole managed policy will continue working for all currently attached users, groups, and roles. However, after July 5, 2022, the AWSConfigRole managed policy can’t be attached to any new users, groups, or roles. The policy will also not be updated to include permissions for newly supported resource types and new managed rules.

In this post, we’ll provide guidance on how to identify use of the AWSConfigRole policy and how to replace that policy with the new AWS_ConfigRole policy.

Who is affected by this policy change?

When setting up AWS Config, customers have the option to select the AWS Config service linked role or create their own role for AWS Config to leverage. If you’re a customer that uses the AWS Config service linked role, AWSServiceRoleForConfig, then you don’t need to take any action with this impending policy depreciation/change, because the service linked role uses a different AWS Identity and Access Management (IAM) policy (not AWSConfigRole or AWS_ConfigRole). If you’re a customer who chose not to use the service linked role and created a new role for AWS Config to use, then you must check which policy is attached to that role. If the role has AWSConfigRole policy attached, then you must detach that policy and then attach AWS_ConfigRole.

What happens if I use the legacy policy and don’t take any action?

Because the policy AWSConfigRole will no longer be updated, AWS Config won’t work properly in the future, as new resource types won’t be added to that policy. This means that AWS Config won’t be able to record those new resource configuration changes, and it will start generating access denied errors, which are logged in AWS CloudTrail.

Identifying use of legacy IAM policy

In this section, we’ll walk you through how to identity if you’re using the legacy IAM Policy using AWS Config Advanced Queries. You can use AWS Config to query the current configuration state of AWS resources based on configuration properties for a single account and Region or across multiple accounts and Regions. You can perform ad hoc, property-based queries against current AWS resource state metadata across all resources that AWS Config supports. The advanced query feature provides a single query endpoint and a powerful query language to get the current resource state metadata without performing service-specific describe API calls. You can use configuration aggregators to run the same queries from a central account across multiple accounts and AWS Regions. For more information, go here.

Steps to run an AWS Config Advanced Query

  1. Log in to the account where you have set up a configuration aggregator and go to the AWS Config service console. To confirm that you’ve setup the configuration aggregator, select Aggregators on the left panel of the console, and you should find a radio button selected next to a previously configured Aggregator. This confirms that you’ve setup an Aggregator. Note that the aggregators source can be configured at the account or at the AWS Organizations level.
Figure 1. AWS Config Aggregators

Figure 1. AWS Config Aggregators

If you need to set up an Aggregator, follow the steps outlined here and in the post here.

  1. Now that you’ve confirmed or setup a new configuration Aggregator, select Advanced Query, on the left panel of the AWS Config console, then select New Query and paste the following in the New Query section:
SELECT 
    accountId, 
    arn, 
    resourceId, 
    resourceName, 
    resourceType, 
    tags, 
    configuration.attachedManagedPolicies 
WHERE 
    resourceType = 'AWS::IAM::Role' 
    AND configuration.attachedManagedPolicies.policyName = 'AWSConfigRole'
  1. Let’s set the Query Scope to be our DelegatedAdminAccountAggregator, which is our configuration Aggregator. Make sure that at least one of the Regions per account that you are targeting to run the query has global resources enabled for the recorder to be able to pull IAM resources.
Figure 2. Running AWS Config Advanced Queries

Figure 2. Running AWS Config Advanced Queries

  1. Now select Run.
  2. If the AWSConfigRole managed policy is currently attached to an IAM role, then you should see a list of IAM roles. If there are no results from this query, then you have nothing further to do and this post doesn’t impact your AWS Config setup.

Implementing AWS Config’s New IAM Policy

In this section, we’ll walk you through how to update from the legacy custom IAM Policy AWSConfigRole. We recommend that you use the same deployment method as you did to deploy the original IAM role used by Config to make the following changes. We’ll provide three deployment options for making this update. The first option is applicable if you used AWS CloudFormation StackSets to originally configure and enable AWS Config, and this will require you to update your CloudFormation StackSet and deploy the update. The second is applicable if you enabled AWS Config manually via the console; in which case, you can use the Identity Console to update the IAM Role. And the third option is applicable if you’re an AWS Control Tower  user, in which case you must make sure that you’re running version 2.9 or later. For this option, AWS Control Tower will update Config to use the service linked role, which doesn’t use either AWSConfigRole or AWS_ConfigRole. Let’s walk through each scenario in detail.

Scenario 1: Update via CloudFormation StackSets

If you originally used CloudFormation StackSets to set up a custom IAM role, rather than the service linked role, for AWS Config to leverage in your multi-account environment, then you can simply update the StackSet template to use the new IAM managed policy and the StackSet will update the roles across your accounts. To do this, follow these steps:

  1. In the Region and AWS account where you originally deployed the CloudFormation StackSet to setup the AWS Config role, navigate to the CloudFormation StackSet console.
  2. Select the StackSet that deployed the AWS Config role.
  3. Select the Template tab, and then the Copy to clipboard.
  4. In a text editor of your choice, paste the CloudFormation template that you copied from the StackSet console.
  5. Update any references of arn:aws:iam::aws:policy/service-role/AWSConfigRole
    to  arn:aws:iam::aws:policy/service-role/AWS_ConfigRole.
  6. The following is a sample template snippet before and after an update:

Sample old template

Resources:
  LegacyConfigRole:
    Type: 'AWS::IAM::Role'
    Properties:
      RoleName: 'ExampleConfigRole'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - config.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      Path: /
      ManagedPolicyArns:
        - 'arn:aws:iam::aws:policy/service-role/AWSConfigRole'

Sample new template

Resources:
  LegacyConfigRole:
    Type: 'AWS::IAM::Role'
    Properties:
      RoleName: 'ExampleConfigRole'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - config.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      Path: /
      ManagedPolicyArns:
        - 'arn:aws:iam::aws:policy/service-role/AWS_ConfigRole'
  1. Save this updated template locally on your computer.
  2. Back in the CloudFormation console of the original StackSet, select the Actions drop down and Edit StackSet details.
Figure 3. Editing a StackSet

Figure 3. Editing a StackSet

  1. In the “Choose a template” step of updating the StackSet, select Replace current template and then Upload a template file. Choose the file that you saved locally. This should look similar to the following screenshot. If it is, then select Next.
Figure 4. Updating a StackSet Template

Figure 4. Updating a StackSet Template

  1. In the “Specify StackSet details” and “Configure StackSet Options” steps of updating the StackSet, keep the options/parameters the same, and select Next.
  2. In the “Set deployment options” step of updating the StackSet, the settings will depend on your Organizational structure. In the following example, the organization has two organizational units (OUs) and all accounts are under those two OUs. If you have a flat structure to your account setup, then you must select Deploy to accounts and paste or upload a CSV of your account numbers.
Figure 5. Deploying a StackSet to Organizational Units (OUs)

Figure 5. Deploying a StackSet to Organizational Units (OUs)

  1. In the specify regions section, select Add all regions. Then, select Next to continue on to the next step updating the StackSet.
  2. In the “Review” step of updating the StackSet, scroll to the bottom and make sure that I acknowledge that AWS CloudFormation might create IAM resources with custom names is checked. Then, select Submit.
  3. After submitting the changes to the StackSet, it will take a few minutes to push the changes to your accounts. The length of time will depend on how many accounts you have. In the Operations tab, you can monitor the overall Status of the operation. You should see a status of SUCCEEDED when the operation is completed. You can also monitor the status of the stack instances for each account in the Stack instances tab. The Status of each stack instance should be CURRENT when the updates have been pushed to that account.

Scenario 2: Update via AWS Identity Console

If you enabled and configured AWS Config manually via the AWS Console, you can use the following details to make the necessary updates after you’ve gone through the earlier steps outlined in this post to determine which AWS accounts are still using the legacy policy. Do this activity for each AWS account that must be updated.

  1. To update the policy, navigate to the IAM console and select “Roles” on the left panel under the Access management sub-heading.
  2.  Enter the name of the role that you are currently using for AWS Config in the search field, select “Add Permissions”, then select “Attach existing policies directly”, enter in the policy name “AWS_ConfigRole” [see Figure 6 below] and select that policy, then select “Next: Review” and “Add Permissions”.
  3.  Then, remove the old policy AWSConfigRole by selecting the “X” on the right-hand side of the console.
    Note that you may also choose to make these updates via the AWS Command Line Interface (AWS CLI) or via the AWS SDK.
Figure 6. Attach the updated AWS_ConfigRole policy

Figure 6. Attach the updated AWS_ConfigRole policy

Scenario 3: Confirm AWS Control Tower version and update if required

If you enabled AWS Config through setting up AWS Control Tower, you must make sure that your Control Tower Landing Zone version is at least at version 2.9. This version of the Landing Zone will update your AWS Config role to the service linked role. To verify and upgrade the Landing Zone version that you’re using, follow these steps:

  1. In the Region and AWS account where you originally deployed your AWS Control Tower environment, log in to the AWS Console and navigate to the AWS Control Tower dashboard.
  2. On the left pane, select Accounts. If your accounts are all using the most up-to-date Landing Zone configuration, then their State will be listed as “Enrolled”. If there are accounts with a dated Landing Zone configuration, then their State will be listed as “Updated available”. In the following, you can see an example of all of the accounts in a certain OU, Custom, using a legacy Landing Zone configuration.
Figure 7. Control Tower Accounts

Figure 7. Control Tower Accounts

  1. To update all of the accounts in an OU, select the OU to upgrade from the Accounts table. In the above case, you would select Custom. From the OU page, select Actions and then Re-Register OU.
Figure 8. Re-Registering an OU in Control Tower

Figure 8. Re-Registering an OU in Control Tower

  1. If you want to update the Landing Zone configuration of each account individually and not update an entire OU, you can select an account and select the button Update account.
Figure 9. Updating an Account in Control Tower

Figure 9. Updating an Account in Control Tower

Upon completion of the upgrade to Landing Zone version 2.9, the role used by AWS Config will be updated to the service linked role.

Conclusion

In this post, we discussed upcoming changes to the AWSConfigRole managed policy used by AWS Config, and walked you through how to verify if this policy is in use in your AWS environment using AWS Config Advanced Query. In the last section of this post, we walked you through how to replace the policy with the updated version by updating a previously deployed StackSets, manually through the Identity Console, and upgrading your AWS Control Tower Landing Zone version. Note that this only affects customers who aren’t using the AWS Config service linked role AWSServiceRoleForConfig. If the AWS_ConfigRole policy is active in your AWS environment, then make our suggested updates before July 5, 2022, to make sure of continued functionality for all newly-supported resources types and managed rules.

Authors:

Megan O’Neil

Megan is a Principal Specialist Solutions Architect focused on threat detection and incident response. Megan and her team enable AWS customers to implement sophisticated, scalable, and secure solutions that solve their business challenges. Outside of work, Megan loves to explore Colorado including mountain biking, skiing and hiking.

Anna McAbee

Anna is a Security Specialist Solutions Architect focused on threat detection and incident response at AWS. Before AWS, she worked as an AWS customer in financial services on both the offensive and defensive sides of security. Outside of work, Anna enjoys cheering on the Florida Gators football team and traveling the world.