When deploying RDS and S3 Buckets for tag compliance as AWS config rules, all resources are being included in the filter

I believe this is related to https://github.com/capitalone/cloud-custodian/issues/801 but I wanted to report this as well, because it has serious implications.

If I run a tagging compliance policy for RDS and S3 buckets via dryrun mode AND explicitly pass in the region, I get the correct results. However, if I deploy the policy as an AWS config rule, every one of my S3 and RDS resources seems to be included as non-compliant, even when I’m passing in region at the command line. Fortunately, I did not have any actions enabled (we’ll be deleting them once this is filtering properly).

Here are the policies:

- name: rds-tag-compliance
  resource: rds
  description:
    Terminate an RDS through a config rule
    if it does not comply with tagging best practices.
    The instance will be terminated within 15 minutes.
  mode:
      type: config-rule
  filters:
    - "tag:CostCenter": absent

- name: s3-tag-compliance
  resource: s3
  description:
    Terminate an S3 through a config rule
    if it does not comply with tagging best practices.
    The instance will be terminated within 15 minutes.
  mode:
      type: config-rule
  filters:
    - "tag:CostCenter": absent

[kapilt]

yeah the issue is effectively that all tags are missing on a handful of resource types rds, rds snapshots, app elb, and s3 buckets since its considered by config to be a supplementary field. for config rules not using those fields no issues. for those that are, results will be misleading since there are no tag values to validate against. the referenced pull request merges the supplementary config to get config and other data back into the resource when custodian evaluates it.

[caversa]

Kapil, sounds like you’ve found the issue, but I wanted to provide a little extra information in case it helps. On Friday I created a config rule where I was specifying a tag value to search for (looking for an obsolete Cost Center), and that worked properly, so the issue seems to be specific to searching for the absence of the tag.