Add tagging support to AWS IAM Policies

[trastle]

Add tag loading and tagging to AWS IAM Policies.
Resolves: #6679

[trastle]

I've fixed the tests that needed additional or changed resources in the test fixtures.
I have, currently, resolved these by making the minimum change rather than replacing the existing recording.

There is one test, the remaining failure, that I am uncertain how to fix as I'm uncertain exactly what its testing:

 =================================== FAILURES ===================================
______________ PolicyMetaLint.test_resource_shadow_source_augment ______________
[gw1] linux -- Python 3.6.13 /home/runner/work/cloud-custodian/cloud-custodian/.tox/py36/bin/python
Traceback (most recent call last):
  File "/home/runner/work/cloud-custodian/cloud-custodian/tests/test_policy.py", line 175, in test_resource_shadow_source_augment
    % (", ".join(shadowed))
  File "/opt/hostedtoolcache/Python/3.6.13/x64/lib/python3.6/unittest/case.py", line 670, in fail
    raise self.failureException(msg)
AssertionError: iam-policy have resource managers shadowing source augments

[ajkerrigan]

Thanks for the PR!

There is one test, the remaining failure, that I am uncertain how to fix as I'm uncertain exactly what its testing:
...
AssertionError: iam-policy have resource managers shadowing source augments

Ok, that's happening because augments can be source-specific. By default, the resource manager defers to the source to handle augments. This test sees that the iam-policy resource has a Config source defined, but defines a custom augment at the resource manager level. I think that's actually what we want here, but that shadow test goes back a long while and seems like a good general idea for consistency and to avoid surprises. (Config sources also get tags automatically for some resources, though that doesn't seem to be the case here.)

Given all of that context, I think the smoothest way forward would be to define augments per source. Which would mean something like this for the existing DescribePolicy source, and then a new custom Config source with the same augment.

[kapilt]

the shadow augment catch is valid here, config source already has tags, so redundantly fetching them when that's the source on a manager augment is not good, this should be on a describe source subclass overriding the augment method on it.

[trastle]

Sorry for the slow reply on this one folks. I added the previous patch to my workflow and forgot a little about the PR.

I've implemented the above suggested change, moving the augment to the existing DescribePolicy class from the Policy object itself.

This has made the automated tests happy (a rebase was also needed) and I can confirm this works in my environment also.

[kapilt]

lgtm, thanks

[kapilt]

i do wonder if we want to do a follow up branch to default to only customer managed policies wrt to server side query.

[trastle]

i do wonder if we want to do a follow up branch to default to only customer managed policies wrt to server side query.

I cannot comment for all users of this but I'm certainly filtering down to just my customer policies when I am running my policies. A default or some intuitive way to do this would be welcome.