turbot / steampipe-mod-aws-tags

Is your AWS tagging strategy following best practice? This mod checks if your AWS resource tags are set correctly to help you manage them effectively using Powerpipe and Steampipe.
https://hub.powerpipe.io/mods/turbot/aws_tags
Apache License 2.0
19 stars 8 forks source link

"Tagging resources" controls feel too heavy / redundant with other controls #18

Closed e-gineer closed 2 years ago

e-gineer commented 2 years ago

For my mandatory tags run, I have 8,910 alarms of which 6.962 are from "Tagging resources". This feels wrong.

Should tagging resources be broken up into per-service information? Or is service information redundant relative to this control?

I believe the same problem exists for limit, mandatory, etc:

/src/steampipe-mod-aws-tags $ grep -r tagging_resource .
./CHANGELOG.md:- tagging_resource
./controls/mandatory.sp:    control.tagging_resource_mandatory,
./controls/mandatory.sp:control "tagging_resource_mandatory" {
./controls/mandatory.sp:  sql         = replace(local.mandatory_sql_region, "__TABLE_NAME__", "aws_tagging_resource")
./controls/untagged.sp:    control.tagging_resource_untagged,
./controls/untagged.sp:control "tagging_resource_untagged" {
./controls/untagged.sp:  sql         = replace(local.untagged_sql_region, "__TABLE_NAME__", "aws_tagging_resource")
./controls/prohibited.sp:    control.tagging_resource_prohibited,
./controls/prohibited.sp:control "tagging_resource_prohibited" {
./controls/prohibited.sp:  sql         = replace(local.prohibited_sql_region, "__TABLE_NAME__", "aws_tagging_resource")
./controls/limit.sp:    control.tagging_resource_tag_limit,
./controls/limit.sp:control "tagging_resource_tag_limit" {
./controls/limit.sp:  sql         = replace(local.limit_sql_region, "__TABLE_NAME__", "aws_tagging_resource")

cloud steampipe io_org_acme_workspace_awsmulti_dashboard_aws_tags benchmark mandatory

cbruno10 commented 2 years ago

@e-gineer I agree, it does seem redundant to query the aws_tagging_resource table when we have individual controls per resource type also.

One alternative approach could be to use the aws_tagging_resource table exclusively, but there are limitations, as only a subset of services are supported. So it seems like we'd need individual controls for non-supported services anyway.

So I think the following approach would give us the widest coverage while also reducing redundancy: