This feature would help with identifying when potentially dangerous IAM actions - such as those that could cause resources to be exposed to anonymous users (Principal = *).
The automation would involve scraping this page to flag changes to AWS services under the “resource based policies” column.
Here’s an example of how this could help: AWS recently announced that CodeBuild supports resource based policies. However, the associated IAM actions - codebuild:PutResourcePolicy and codebuild:DeleteResourcePolicy were labeled as “Write” access level instead of the “Permissions management” level under the actions, resources, and condition keys page for CodeBuild. This happens on a regular basis, which has ramifications in two major cases:
The AWS visual policy editor relies on the accuracy of the actions, resources, and condition keys page. It allows you to select all actions under an access level. I cover this material here: https://policy-sentry.readthedocs.io/en/latest/introduction/comparison-to-similar-tools.html#aws-console-visual-policy-editor. Obviously, if you want to grant someone the ability to “write” to CodeBuild, that doesn’t mean you want them to share CodeBuild projects with external accounts or the internet at large. If the IAM actions tracker tool tracked the changes to the Resource based policies in the “AWS services that support IAM” documentation, it would help us identify which services we should inspect for the IAM actions that grant privileges to modify those resource based policies. It will also help us notify AWS that they should fix the documentation.
Since we rely on the accuracy of this documentation for Policy Sentry to automate the creation of least privilege IAM policies, Our attitude was that we couldn’t wait for AWS to make fixes to the access levels - especially when it comes to Permissions management actions that are mislabeled. If IAM Actions tracker were able to track the changes to the “AWS services that support IAM” page, we could quickly make changes to the overrides file, rather than the informal manual searching method that we take right now.
This feature would help with identifying when potentially dangerous IAM actions - such as those that could cause resources to be exposed to anonymous users (Principal = *).
The automation would involve scraping this page to flag changes to AWS services under the “resource based policies” column.
Here’s an example of how this could help: AWS recently announced that CodeBuild supports resource based policies. However, the associated IAM actions -
codebuild:PutResourcePolicy
andcodebuild:DeleteResourcePolicy
were labeled as “Write” access level instead of the “Permissions management” level under the actions, resources, and condition keys page for CodeBuild. This happens on a regular basis, which has ramifications in two major cases:Let me know if you have any questions.