How to Record and Govern Your IAM Resource Configurations Using AWS Config

AWS Config recently added the ability to record changes to the configuration of your AWS Identity and Access Management (IAM) users, groups, and roles (collectively referred to as IAM entities) and the policies associated with them. Using this feature, you can record configuration details for these IAM entities, including details about which policies are associated with them. AWS Config automatically records changes to any of these resources, and gives you a full history of the previous configurations for these resources. With this information, you can determine, for example, if an IAM user has used policies that gave him access to certain resources or if certain actions were permitted at any point in the past. The AWS Config console includes a timeline view of this information.

AWS Config also recently launched AWS Config Rules in the US East (N. Virginia) region. Config Rules enable you to set up rules that check the validity of changes made to resources being tracked by AWS Config. These rules can be set up to evaluate each change to the configuration of a resource or to evaluate changes at a set frequency, and you can author your own rules in any language supported by AWS Lambda.

Using Config Rules on IAM resources, you can codify your best practices for using IAM and assess the compliance state of these rules regularly. In this blog post, I will show how to start recording the configuration of IAM resources, and author an example rule that checks whether all IAM users in the account are using a sample managed policy, MyIAMUserPolicy. I will also describe examples of other rules customers have authored to assess their organizations’ compliance with their own standards.

Setting up AWS Config to record IAM resources

Setting up AWS Config is quick and simple. By default, changes to your IAM resources are not recorded by AWS Config. If you operate in several AWS regions, you will first need to determine a “home” AWS region where you want AWS Config to record and store configuration changes to IAM resources, because the same IAM data is available in different AWS regions. When you have determined your home region, you can simply select the Record all resources supported in this region and Include global resources check boxes on the AWS Management Console, as shown in the following screenshot. You can also choose to enable only IAM resources by clearing these check boxes, and instead selecting IAM resources from the Specific types drop-down menu. For additional details or to set up AWS Config by using the command-line interface, see Selecting Which Resources AWS Config Records.

AWS Config supports IAM users, groups, and roles, as well as policies managed by you. A versioned history of AWS managed policies is already available in the IAM console. Inline policies associated with IAM entities are tracked as part of the configuration of those IAM entities.

Authoring a custom AWS Config rule to check that a single approved IAM policy is in use

I will now set up a new AWS Config rule that checks whether all IAM users (with the exception of a single user, such as an admin user) in my account are using only the MyIAMUserPolicy policy created and managed by me, and are not using any other policy. You would set up this type of rule to ensure all “standard” IAM users have the same level of permissions that you are managing through MyIAMUserPolicy. For a detailed walkthrough that shows how to create a customer managed policy, see this tutorial.

To create this rule, I will first confirm that IAM users and policies are available in AWS Config by looking up IAM Users and IAM Roles in the AWS Config Lookup page. In the following screenshot, you can see all IAM users and roles in my account are available to Config.

Clicking the  icon next to one of the users or roles will take me to the Config Timeline that shows the most recent configuration recorded for that resource.

Next, I will set up the new rule in AWS Config and write the AWS Lambda function for the rule. To do this, I click Add Rule in the AWS Config console, and then I click Create AWS Lambda function to set up the function I want to execute.

To help set up this Lambda function in the Lambda console, I simply use the config-rule-change-triggered blueprint and get started. I look at the code in this blueprint and change the evaluateCompliance function to check for the following.

if (ruleParameters.exceptionList === configurationItem.resourceName) {
        return 'NOT_APPLICABLE';       
   }
if (configurationItem.configuration.attachedManagedPolicies[0].policyName === ruleParameters.desiredPolicyName){
        if ((configurationItem.configuration.attachedManagedPolicies[1]) || (configurationItem.configuration.userPolicyList[0])) {
                return 'NON_COMPLIANT';
    } else {
        return 'COMPLIANT';
    }
}

This code snippet assumes that exceptionList and desiredPolicyName are parameters passed into the function. The function simply checks whether the IAM user is not the exception, and if not, it verifies that only one managed policy, desiredPolicyName, is attached to the user. Any other managed policy or inline policy will mark this resource noncompliant.

After I provide the appropriate permissions, I save the Lambda function and move back to the Config console, where I set up the following custom Config rule.

This rule is evaluated immediately after I first create the rule and, subsequently, when any changes are made to the IAM user (change in configuration, attachment of policies, change in inline policies, etc.). This rule will not apply to the admin user and will check that only MyIAMUserPolicy is attached to any other IAM user.

After you save this rule, it executes and evaluates IAM users. If this rule finds an inline policy or any other managed policy associated with the IAM user, the user is noncompliant. For example, on my account, one user teststadion has the appropriate configuration to be compliant, but IAM user DBSuperUser has two customer managed policies attached to it and is therefore noncompliant.

The Compliant or Noncompliant state for each rule is also sent via SNS notifications, which you created when you set up AWS Config. You can configure these notifications to send an email, trigger a corrective action, or log a ticket. The payload of the SNS notification contains full details about the change in compliance state and the resources and configuration details that may have contributed to noncompliance. In the following example notification, an IAM user subject to the standardized-iam-policies-for-all-users rule moved to COMPLIANT on January 7, 2016, at 7:21 GMT; it was previously NON_COMPLIANT on January 7, 2016, at 3:54 GMT.

Subject: [AWS Config:us-east-1] AWS::IAM::User AIDAJZVIMU2CBP4WCMW6S is COMPLIANT with standardized-iam-po.
{
  "awsAccountId": "232378813418",
  "configRuleName": "standardized-iam-policies-for-all-users",
  "configRuleARN": "arn:aws:config:us-east-1:232378813418:config-rule/config-rule-qkzfp4",
  "resourceType": "AWS::IAM::User",
  "resourceId": "AIDAJZVIMU2CBP4WCMW6S",
  "awsRegion": "us-east-1",
  "newEvaluationResult": {
    "evaluationResultIdentifier": {
      "evaluationResultQualifier": {
        "configRuleName": "standardized-iam-policies-for-all-users",
        "resourceType": "AWS::IAM::User",
        "resourceId": "AIDAJZVIMU2CBP4WCMW6S"
      },
      "orderingTimestamp": "2016-01-07T07:21:06.552Z"
    },
    "complianceType": "COMPLIANT",
    "resultRecordedTime": "2016-01-07T07:21:15.749Z",
    "configRuleInvokedTime": "2016-01-07T07:21:15.520Z",
    "annotation": null,
    "resultToken": null
  },
  "oldEvaluationResult": {
    "evaluationResultIdentifier": {
      "evaluationResultQualifier": {
        "configRuleName": "standardized-iam-policies-for-all-users",
        "resourceType": "AWS::IAM::User",
        "resourceId": "AIDAJZVIMU2CB!  P4WCMW6S  "
      },
      "orderingTimestamp": "2016-01-07T03:33:26.692Z"
    },
    "complianceType": "NON_COMPLIANT",
    "resultRecordedTime": "2016-01-07T03:54:13.395Z",
    "configRuleInvokedTime": "2016-01-07T03:54:10.400Z",
    "annotation": null,
    "resultToken": null
  },
  "notificationCreationTime": "2016-01-07T07:21:15.942Z",
  "messageType": "ComplianceChangeNotification",
  "recordVersion": "1.0"
}

Security-related use cases that you can address with IAM and Config Rules

The preceding example is one of several security-related use cases you can address with AWS Config Rules for IAM resources. We have received good feedback from customers about new use cases they are addressing with this capability. The following list includes representative examples of this feedback:

1. Frequently verify that my managed policies that are critical and used in production have not been modified.
2. Check that IAM roles used by Amazon EC2 instances do not have IAM (iam*) privileges in any of the attached policies.
3. Check if IAM users are adhering to a specified password policy with specific attributes.
4. Check that no IAM roles have permissions to modify security groups.
5. Verify that any policy associated with an IAM entity (barring a specified exceptionList) does not have createUser or createRole permissions in the policy document.

Additionally, customers subject to compliance guidelines are codifying configuration best practices specified by their auditor or compliance regime into rules that help developers and other users govern configurations themselves.

Feel free to post questions or comments in the “Comments” section below, or contact us on the AWS Config forum.

– Prashant