turbot / steampipe-mod-aws-tags Goto Github PK

Describe the bug
The current version of the mod returns a warning due to using the deprecated option version instead of min_version for the aws plugin.

This issue can be trivially resolved by updating

  require {
    plugin "aws" {
      version = "0.81.0"
    }
  }

to

  require {
    plugin "aws" {
      min_version = "0.81.0"
    }
  }

Steampipe version (steampipe -v)
Example: v0.3.0

Plugin version (steampipe plugin list)
Example: v0.5.0

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
Looking at the Steampipe docs I can’t see controls that allow for the querying of tags against Organizational resources, such as

• AWS accounts
• Organizational units
• The organization’s root

These resources support tags are documented per AWS docs https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tagging.html

Describe the solution you'd like
Once tables have been added with the tag column controls should be added to surface the additional tag data

Describe alternatives you've considered
None

Additional context
None

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

I have two AWS accounts, call them jon-personal and jon-public. I can query them both by their names in my aws.spc. For the mod, though, it seems I need to reduce the aws.spc to a single uncommented entry in order to run control.s3_bucket_untagged, is that expected?

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")

Describe the bug
A clear and concise description of what the bug is.

Below is the example outcome, where S3 buckets are evaluated based on s3_bucket_expected_tag_values

steampipe check control.s3_bucket_expected_tag_values

The query evaluates non-tagged buckets as OK; by nature of this mod, we should validate whether buckets are tagged with proper values specified in the .spvar file or not; in case the tag is missing, the control should show as **skip**

Steampipe version (steampipe -v)
Example: v0.3.0

Plugin version (steampipe plugin list)
Example: v0.5.0

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
❌ No

It is a feature that I need in my company, so I want to develop on this public repo 😄

Describe the solution you'd like
For some tags, we may want to restrict values.
For example, a tag Environment should only be Prod, Staging or Dev

In my company we use steampipe-mod-aws-tags to list resource with missing tags, but we also need to find resources with wrong tag (having consistent tags is useful to monitor costs!)

When getting a mod with variables through mod get, if there are no defaults defined and no values defined locally, any steampipe command will then prompt the user for those variables. We should add defaults and provide instructions with a sample Steampipe variable file for a smoother mod get experience and local experience as well.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Resources that have no tags do not always pass the 'is null' test.

Steampipe version (steampipe -v)
Steampipe v0.20.9

Plugin version (steampipe plugin list)
hub.steampipe.io/plugins/turbot/aws@latest 0.113.0 aws

To reproduce

select arn from aws_dynamodb_table where tags is null
+-----+
| arn |
+-----+
+-----+
select arn from aws_dynamodb_table where (tags is null or not exists (select 1 from jsonb_object_keys(tags)))
+------------------------------------------------------------------+
| arn |
+------------------------------------------------------------------+
| arn:aws:dynamodb:ap-southeast-2:account-id:table/my-lock-table |
+------------------------------------------------------------------+
select arn, tags from aws_dynamodb_table where arn='arn:aws:dynamodb:ap-southeast-2:account-id:table/my-lock-table'
+------------------------------------------------------------------+------+
| arn | tags |
+------------------------------------------------------------------+------+
| arn:aws:dynamodb:ap-southeast-2:account-id:table/my-lock-table | {} |
+------------------------------------------------------------------+------+

Expected behavior
Empty tags objects that for whatever reason do not pass the 'is null' test, should still be counted as empty and the resource they are associated with marked as 'untagged'.

Additional context
I do not know why certain empty tag objects are failing the 'is null' check while others pass.