Right now we obliterate the contents of the file on each generation. Instead we should parse the files and determine which records are already in there. Then we can append the new entries. This way we can add human comments to the files or split up big ones, etc.

Caveat: when moving an entry from the "actions without APIs" or "APIs without actions" lists to the sane list, that involves reordering - probably want to bring comments along for the ride somehow 🤔

In https://github.com/glassechidna/trackiam/blob/master/services/execute-api.yml, under the "# APIs without an IAM action section, I can see there are some APIs that look like IoT APIs, but I'm not sure how they're related to the execute-api service (which I usually associate with API Gateway).

There's also the execute-api:UpdateTopicRuleDestination API, which I don't find an equivalent for in the IoT service yml, but I do see listed in the AWS API docs - UpdateTopicRuleDestination.

So I guess my question is how do these execute-api APIs relate to IoT, and should I use one over the other when looking for a definitive list of IoT APIs? Thanks!

In addition to the current linking out to the diff

Sometimes I only care about

• Specific regions
• Specific services

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html

• regions
• availability zones?
• services
• different detection mechanisms (published json, dns polling, etc)

We should do some...

It redirects to https://aktion.io/. I'm getting this error:

@aidansteele FYI

So that you can send a link of the diff you're currently viewing to someone else

• If we create a GitHub "release" for each commit, people can subscribe to the repo to receive notifications.
• We can also create some public SNS topics and publish messages to them whenever a change is committed.
• Twitter too

Could use an IAM role with zero permissions, so no costs are incurred. Though I think some services might only record successful API calls. We should also compare results to any public docs from AWS

Should we have one?

e.g. iq and iq-permission

e.g. it could say

connect added 4 new APIs without IAM actions, ec2 added 3 new IAM actions.

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'services/IVS.yml'
  'services/ivs.yml'

https://github.com/glassechidna/trackiam/blob/master/services/ivs.yml
https://github.com/glassechidna/trackiam/blob/master/services/IVS.yml
"The prefix and the action name are case insensitive"

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:

1. 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.
2. The issue of incorrect Access level labeling is so severe that we had to build in an Access Level Overrides file in Policy Sentry: https://github.com/salesforce/policy_sentry/blob/master/policy_sentry/shared/data/access-level-overrides.yml
3. 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.

Let me know if you have any questions.