Page History

...

1. Login to the cu-training AWS account using traditional Shibboleth login.
   1. Use this link to initiate login: https://signin.aws.cucloud.net/
   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".
2. 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".
3. In the AWS Management Console, type "config" in the search box and click on "Config" under " under Services".
4. In the Config Dashboard, take note of the high numbers of non-compliant resources. (100+ resources)

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.
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.
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 inded indeed non-compliant with respect to the 251-MED-no-iam-users-except-whitelist rule.
6. In the top right of that page, click on "Manage Resource".

Part 1C – Whitelist "your" IAM user

1. You should now be viewing "your" IAM user in the the IAM console.
2. Click on the "Tags" tab tab.
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

...

To be conservative, the Cornell 153-HIGH-s3-bucket-public-read-prohibited Config rule Rule flags any S3 buckets that are publicly readable. However, there are valid use cases where you want S3 bucket contents to be publicly readable (e.g., public web resources).

...

Part 2B – Find "your" S3 bucket

1. Click on "Resources" from  from the left-hand navigation panel in the Config console.
2. In the "Resource identifier" search  search field, enter "your" S3 bucket name using this pattern my-bucket-web-site-NETID, and hit "enter" on your keyboard.
3. Config should show one search result, listing an S3 bucket user named like my-bucket-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.
6. In the top right of the details page, click on Manage Resource. This will take you to the S3 console for that bucket.

Part 2C – Whitelist "your" bucket

1. Click In the S3 console, with "your" bucket selected, click on the Properties tab and scroll down to Tags.
2. Click Edit in the tags section.
3. Click on Add tag.
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
5. On resulting bucket Properties page confirm that your new tag is shown as one of the bucket tags.

...

In a typical Config workflow you would whitelist, reconfigure, or delete resources that Config has flagged and then tell Config to re-evaluate the relevant Rules. However, the Config API has very, very low thresholds for how often re-evaluations can be triggered. Therefore we need to coordinate this next step, and there are other complicating factors.

Part 3A – Find "your" resources in Config again

...

• In all likelihood one, if not both, of "your" resources remain flagged as non-compliant. 
• 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 cached 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.

...