When I run python3 cloudmapper.py audit --accounts {{account}} and {{account}} has a user and/or group with a "known bad policy" (as defined by the KNOWN_BAD_POLICIES dictionary in shared/iam_audit.py), the Cloudmapper output indicates that those known bad policies are owned by a (wrong) role instead of a user or group. For example, if I add user data to the demo account data for a user called USER_WITH_BAD_INLINE_POLICY with the arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM policy attached, the output of python3 cloudmapper.py audit --accounts demo shows HIGH - demo (us-east-1) - Known bad policy used: arn:aws:iam::123456789012:role/level3. This level3 role doesn't have a known bad policy attached. From the testing I've done, it looks like shared/iam_audit.py is creating a finding using the role variable that is used while iterating over the roles in an account, instead of creating a finding with the user or group variables that are used for iterating over those respective objects. This bug would go unnoticed as long as known bad policies were only attached to roles.
When I run
python3 cloudmapper.py audit --accounts {{account}}and{{account}}has a user and/or group with a "known bad policy" (as defined by theKNOWN_BAD_POLICIESdictionary inshared/iam_audit.py), the Cloudmapper output indicates that those known bad policies are owned by a (wrong) role instead of a user or group. For example, if I add user data to thedemoaccount data for a user calledUSER_WITH_BAD_INLINE_POLICYwith thearn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSMpolicy attached, the output ofpython3 cloudmapper.py audit --accounts demoshowsHIGH - demo (us-east-1) - Known bad policy used: arn:aws:iam::123456789012:role/level3. Thislevel3role doesn't have a known bad policy attached. From the testing I've done, it looks likeshared/iam_audit.pyis creating a finding using therolevariable that is used while iterating over the roles in an account, instead of creating a finding with theuserorgroupvariables that are used for iterating over those respective objects. This bug would go unnoticed as long as known bad policies were only attached to roles.(running in a virtualenv)