feat: More granular suppressions

Description

When suppressing a rule, I would like to be able to suppress the rule only for a certain section of the resource.

Use Case

One example would be AwsSolutions-IAM5, which is triggered whenever there is a * anywhere in the policy. There are certain CDK methods, like <dynamodbTable>.grantReadWriteData(myRole) that add wildcard actions like kms:ReEncrypt*. This will trigger the nag rule and if I suppress it, I will be unable to detect any other problems on this role that may arise in future.

Proposed Solution

It should be possible to add metadata to rule suppressions that the rules can evaluate based on their specific needs. For example

NagSuppressions.addResourceSuppressions(myResource, [{
  id: 'AwsSolutions-IAM5'
  reason: 'Dynamo Table Access'
  metadata: {
    allowedActions: ['kms:ReEncrypt*']
  }
}]

I realise, that the metadata field will have a different structure for different rules, maybe this can be made type safe by the rule specifying an interface or some kind of validation.

Maybe we can even have a NagSuppressionBuilder that provides a fluent API for this?

Other information

No response

Acknowledge

• I may be able to implement this feature request
• This feature might incur a breaking change

[tkglaser]

You make some excellent points and I like your suggestion of making the appliesTo a simple string array. It still covers all the use cases and is a whole lot easier. So, abandoning the ARN-like rule ids but keeping the string-array filters gives:

// API
NagSuppressions.addResourceSuppressions(myRole, [{
  id: 'AwsSolutions-IAM5, 
  appliesTo: ['Action::kms:ReEncrypt*', `Resource::${myBucket.arnForObjects('*')}`],
  reason: 'My Suppressions',
}])

// CFN
"Metadata": {
  "cdk_nag": {
    "rules_to_suppress": [
      {
        "id": "AwsSolutions-IAM5",
        "applies_to": ["Action::kms:ReEncrypt*", "Resource::arn:aws:s3:::mybucket/*"],
        "reason": "My Suppressions"
      }
    ]
  }

This is probably as tight as we can pack this while still being human-readable. The change to the rules engine should be easy too.

[dontirun]

I like that! I think we could generalize to apply a similar approach could be applied to rules with ports, like EC2RestrictedCommonPorts or log types in AuroraMySQLLogging.