Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

er

Table of Contents

...

Introduction

Excerpt

This hands-on exercise shows how to find work with non-compliant resources in AWS Config and how to whitelist them for Config.

...

  1. Login to the cu-training AWS account using traditional Shibboleth login.
    1. Use this link to initiate login: https://signin.aws.cucloud.net/
      • This will start the usual process for Cornell Two-Step Login process. Complete your two-step login.
      • Once you have finished with DUO, you will be in one of two places. Take your next steps based on where you end up.
    2. If you are given the option of selecting a role, select shib-training under the "cu-training" AWS account, and click on Sign in. 
      Image Added

  1. Once in the AWS Management Console, check which AWS region your console is pointed at. You want "N. Virginia". If your console is in any other region, change it to "US East (N. Virigina) us-east-1".
    Image Added

  2. In the AWS Management Console, type "config" in the search box and click on Config under Services.
    Image Added

  3. In the Config Dashboard, take note of the high numbers of non-compliant resources. (100+ resources)
    Image Added

Part 1B – Find "your" IAM user

  1. Click on Resources from the left-hand navigation panel in the Config console.
  2. Enter the "netid" form of your Cornell email address (e.g., netid@cornell.edu) in the Resource identifier search field and hit "enter" on your keyboard. This will start the search for "your" IAM user.
    Image Added

  3. Config should show one search result, listing an IAM user named like "netid@cornell.edu". That IAM User resource will be labelled as non-compliant.
    Image Added
  4. Click on the IAM user name (i.e., netid@cornell.edu) to drill into that resource.
  5. Review the Rules at the bottom to confirm that "your" IAM user is indeed non-compliant with respect to the 251-MED-no-iam-users-except-whitelist rule.
    Image Added

  6. In the top right of that page, click on Manage Resource.

...

  1. You should now be viewing "your" IAM user in the the IAM console.
  2. Click on the Tags tab.
    Image Added

  3. Click on Add tags.
  4. Add a tag with the following settings, and click Save changes:  
    1. Key: cit:config:251-MED-no-iam-users-except-whitelist
    2. Value: exception
      Image Added

      Image Added
Note

At this point in a typical Config workflow, you would find the 251-MED-no-iam-users-except-whitelist Config Rule and trigger re-evaluation of the rule to confirm that your whitelisting had the desired effect (i.e. making the IAM user compliant for that rule). However, the Config API has a very, very threshold for the number of times that you can invoke revaluations. Therefore, the exercise leading leader will trigger re-evaluation just a few times during this hands-on session.

...

  1. Click on Resources from the left-hand navigation panel in the Config console.
  2. In the Resource identifier search field, enter "your" S3 bucket name using this pattern my-bucketpublic-web-site-NETID, and hit "enter" on your keyboard.
    Image Added

  3. Config should show one search result, listing an S3 bucket user named like my-bucketpublic-web-site-NETID. That bucket will be labelled as non-compliant.
  4. Click on the bucket name to drill into the Config details for that resource.
  5. Review the Rules at the bottom of the page. They will show that the bucket is
    1. compliant with respect to the 003-CRIT-s3-bucket-public-write-prohibited rule, but
    2. non-compliant with respect to the 153-HIGH-s3-bucket-public-read-prohibited rule.
      Image Added

  6. In the top right of the details page, click on Manage Resource. This will take you to the S3 console for that bucket.

...

  1. In the S3 console, with "your" bucket selected, click on the Properties tab and scroll down to Tags.
    Image Added
  2. Click Edit in the tags section.
  3. Click on Add tag.
    Image Added

  4. Add a tag with the following details, and click on Save changes:
    1. Key: cit:config:153-HIGH-s3-bucket-public-read-prohibited
    2. Value: exception
      Image Added

  5. On resulting bucket Properties page confirm that your new tag is shown as one of the bucket tags.
    Image Added

Part 3 – Wait for Config Rule re-evaluation

...

  • In all likelihood one, if not both, of "your" resources remain flagged as non-compliant. (sad)
  • One reason for this is that Config evaluations operate on snapshots of resource configurations, not from an instantaneous reading of the resource details. 
  • Another factor that seems to come into play is that Config evaluation results themselves are cached and sometimes you may be looking at results from the previous evaluation.
  • The secret for maintaining your sanity with Config is to check back with Config for new results on the day after you make resource configuration changes. What you see after 24 hours is typically a meaningful set of results.


Info

If you wanted to force Config to evaluate a Rule within your own AWS account, you would use the Re-evaluate action, as shown below.
Image Added