...
In this exercise, you will use Access Analyzer to find an IAM Role role that allows access from an outside AWS account and remove that access.
We have prepared this AWS accounts the cu-training AWS account with roles named example-role-NETID for each , one for each of the training participants.
...
- Login to the cu-training AWS account using traditional Shibboleth login.
- Use this link to initiate login: https://signin.aws.cucloud.net/
- If you are given the option of selecting a role, select shib-training under the "cu-training" AWS account, and click on Sign in.
- Once in the AWS Management Console, type "iam" in the search box and click on IAM under Services.
- Click on Access analyzer from the left navigation section.
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.
ViriginaVirginia) us-east-1".
Note Unlike other aspects of IAM, Access Analyzers are regional.
Part 1B – Examine the Finding for "your" role
- Under Active findings, use the menu integrated into the filter to search for Resource: example-role-NETID
- Be sure to use the pull-down menu in the search field to select Resource
- Enter example-role-NETID, replacing NETID with your own Cornell NetId (e.g., example-role-pea1)
- Hit "enter" on your keyboard to trigger the actual search.
- Your search should result in one Finding that matches. Click on the Finding ID for that record to drill into the finding.
- Note the finding details:
- External principal (IAM Role): arn:aws:iam::2251********:role/bad-actor
- Access level: sts:AssumeRole
- This indicates that our role (example-role-NETID) allows the bad-actor role from a different account to assume it. Those permissions are defined by the Trust Policy in our role.Note
Note |
---|
In real life situations, note Note that the bad-actor Role didn't have anything to do with our creation of the example-role-NETID Role in our account and trusting the bad-actor Role. Someone (or something) with appropriate IAM privileges to our account is the only way that example-role-NETID was created or configured. |
...
Part 1C – Remove access by the bad-actor Role
Note |
---|
In this exercise scenario, we named the outside role bad-actor. In real life, roles are not usually so conveniently named. Also, note that just Just because a Role within your AWS account trusts IAM Roles or Users from another account, it doesn't mean that access is inappropriate or unnecessary. Cross-account access is perfectly fine and often necessary. For example, that is how CloudCheckr accesses our Cornell AWS accounts to do the information gathering it does to provide its services to Cornell. |
For the purposes of this exercise, we'll claim that bad-actor no longer has need for (or never should have had) the cross-account access defined in example-role-NETID. To remove that access, we have two options:
- Delete the entire example-role-NETID Role.
- Change the trust policy for example-role-NETID so that is it no longer allows the bad-actor Role to assume it.
The In real life, the appropriate course of action depends on the situation. For the purposes of this example, we'll just delete the example-role-NETID Role since, in our scenario, none of our own tools or access uses example-role-NETID.
- Back on the
the details page for your finding, click on the Go to IAM console button to see the role details in IAM.
- Click on the Trust relationships tab and note that the role does indeed trust arn:aws:iam::2251********:role/bad-actor
- Click on the Delete role button, and confirm by clicking Yes, delete.
Part 2 – Archive a Finding
...