[RULES] Validate CloudFormation parameter overrides

[corey-cole]

Describe the example rules

The rules check that a set of CloudFormation parameter overrides conform to the new (v2) JSON format for parameters.
If a parameter value contains an ARN, it is checked for correctness via regex.

Edit: The goal of this rule is to shift-left when ARN values are provided as CloudFormation parameters. If parameters represent an ARN but are malformed, it will pass the initial changeset creation but will then fail. This example was driven from a practical requirement where users were managing complex CloudFormation stack parameter JSON documents in Git and wanted a way to apply quality control very early on.

Ensure you meet our example rules submission policy

1. Do not mention any security or compliance regimes in custom messages, file names, rule comments, etc. Example rules are purely for educational purposes and cannot be represented as providing any kind of certification for control regimes like CIS, GDPR, etc [confirmed]

2. Rules should not be duplicates. Please grep the Examples directory contents to ensure that the rules are not already present in another rules file. [confirmed]

3. Rules must include comments or custom messages that describe the function of the rule. [confirmed]

4. If you are adding new rules to an existing rules file, be sure to update the corresponding tests file (YAML file with the same file name prefix) with test inputs which help understand the rules your adding. [N/A]

5. If you are adding a new rules file, be sure to include a corresponding tests file with test inputs which help understand the rules present in the rules file you are adding. [confirmed]

6. The preferred file system structure is:

   1. Examples/<meaningful_name>-tests.yaml
   2. Examples/<meaningful_name>.guard

   Meaningful file names can include AWS resource types, types of checks being done (e.g. “check-lambda-function.guard”), etc.

7. Test your rules by running them against the corresponding tests file. Your pull request description must include a markdown-formatted code block showing the result of your test run (not the logs - just the basic output). [confirmed, see below]

8. Rule file names, rule descriptions, etc. should not make mention of the contributor’s identity. (The connection will already be established by merging the commits.) [confirmed]

NOTE: Please be sure that the templates, rules and logs you provide as part of your bug report do not contain any sensitive information.

Additional context

cfn-guard test --rules-file check-wellformed-parameters.guard --test-data check-wellformed-parameters-tests.yaml
Test Case #1
Name: "DoesNotApplyToEmptyFiles"
  No Test expectation was set for Rule has_likely_valid_arn
  PASS Rules:
    has_correct_keys: Expected = SKIP, Evaluated = SKIP

Test Case #2
Name: "FindsRequiredKeys"
  PASS Rules:
    has_correct_keys: Expected = PASS, Evaluated = PASS
    has_likely_valid_arn: Expected = PASS, Evaluated = PASS

Test Case #3
Name: "FindsMalformedArn"
  PASS Rules:
    has_correct_keys: Expected = PASS, Evaluated = PASS
    has_likely_valid_arn: Expected = FAIL, Evaluated = FAIL

Test Case #4
Name: "ChecksForMissingKeys"
  PASS Rules:
    has_correct_keys: Expected = FAIL, Evaluated = FAIL
    has_likely_valid_arn: Expected = SKIP, Evaluated = SKIP

Add any other context you think is relevant here.

[akshayrane]

@corey-cole Could you please add description for the examples you're willing to contribute? The issue description contains the boilerplate placeholder fields and their description from the template, but it's not clear to us what these example rules are supposed to be used for.

[corey-cole]

@akshayrane I've added additional color on what it does and why it's useful.

[corey-cole]

Following up to see if the additional details are enough or if more is needed.