More nuanced handling of aws-iam-no-policy-wildcards with suffixes

[acdha]

I've run into a number of cases where the aws-iam-no-policy-wildcards is technically correct but doesn't warrant the default HIGH blocking e.g. CI runs because the policies in question had a wildcard suffix. Some examples:

• AWS Secrets Manager with common prefixes for a family of keys, or simply to deal with the random identifier the service appends to the name. An example of the former: "arn:aws:secretsmanager:${var.region}:${data.aws_caller_identity.current.account_id}:secret:manufacturer_key*"
• Systems Manager Parameters targeting a prefix: "arn:aws:ssm:${data.aws_region.current.name}:${data.aws_caller_identity.current.account_id}:parameter${local.ssm_parameter_prefix}*"
• IAM policies granting something like Describe*
• Policies allowing a user to start an SSM session which requires an ARN like "arn:aws:ssm:*:*:session/${aws:username}-*"

Some ideas:

• Adjust the rule level based on the evaluated content so it'd be lower if there's a prefix in the evaluated parameter value
• Update https://aquasecurity.github.io/tfsec/v1.15.1/checks/aws/iam/no-policy-wildcards/ to note that Secrets Manager's random suffix can be more precisely matched using ??????
• Create a second check with a lower priority so someone who adds e.g. # tfsec:ignore:aws-iam-no-policy-wildcard-suffix won't mask an error if some change later causes that value to evaluate to a simple *.
• Specifically filter out Describe*/List* since those are generally safe and that would put the higher priority focus on things which are more likely to have side-effects.

[acdha]

I'll add a closely-related issue which I hit again today and was previously reported as https://github.com/aquasecurity/tfsec/issues/1014 where policies are written using a resource of * because those projects use resource tags to control access.

Here are two examples:

statement {
    resources = ["*"]
    actions = [
      "backup:TagResource",
    ]

    condition {
      test     = "StringLike"
      variable = "aws:RequestTag/Environment"
      values   = [var.global_tags["Environment"]]
    }

    condition {
      test     = "StringLike"
      variable = "aws:RequestTag/Project"
      values   = [var.global_tags["Project"]]
    }
  }

actions = [
  "ssm:StartSession",
]
resources = [
  "arn:aws:ec2:*:*:instance/*",
]
condition {
  test     = "StringLike"
  variable = "ssm:resourceTag/Project"
  values   = ["ExampleProject"]
}
condition {
  test     = "StringLike"
  variable = "ssm:resourceTag/Environment"
  values   = [local.default_tags["Environment"]]
}
condition {
  test     = "BoolIfExists"
  variable = "ssm:SessionDocumentAccessCheck"
  values   = ["true"]
}

I think in both cases it would be relatively easy to shoot yourself in the foot if your conditions were quite broad but the same is also true, arguably more likely, if the devops team is trained to toss # tfsec:ignore:aws-iam-no-policy-wildcards around by reflex.

I think the list of solutions is pretty similar — the one I like the most is having a general rule that the severity goes down if there's a condition (or prefix/suffix in the original case), possibly more than once in the event of multiple constraints: e.g. CRITICAL -> HIGH (prefix/suffix rather than *) or one condition -> MEDIUM/LOW (both patterns & conditions).