Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--strict-checks in ruleset itself #97

Open
jmnarloch opened this issue Nov 9, 2020 · 2 comments
Open

--strict-checks in ruleset itself #97

jmnarloch opened this issue Nov 9, 2020 · 2 comments
Labels
enhancement New feature or request needs-research

Comments

@jmnarloch
Copy link

Describe the bug
What I found surprising is that checks for specific CFN properties are evaluated lazy. What I would expect instead is that across all resources the given rule would be enforced.

Example:

If I define a rule as below:

AWS::DynamoDB::Table BillingMode == PAY_PER_REQUEST

If the resource that it's being evaluated against does not define BillingMode the rule check will be successful, but in this particular case what I am really trying to do is achieve consistency across my template and specify certain behaviour which will be ignored.

To Reproduce
Please supply:

  1. An example rule set and template that results in the error
  2. The commands you used to invoke the tool
  3. The output of a -vvv log level if it's not related to cfn-guard-lambda, or the relevant CloudWatch log messages if it is related to the lambda

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

I had defined a ruleset as follows:

AWS::DynamoDB::Table BillingMode == PAY_PER_REQUEST

and run it against the template:

Resources:
  MyTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: "MyTable"
      AttributeDefinitions:
        -
          AttributeName: "Album"
          AttributeType: "S"
        -
          AttributeName: "Artist"
          AttributeType: "S"
      KeySchema:
        -
          AttributeName: "Album"
          KeyType: "HASH"
        -
          AttributeName: "Artist"
          KeyType: "RANGE"
      SSESpecification:
        SSEEnabled: true

By running command:

cfn-guard check -r rule.ruleset -t emplate.yml

The end result was successful validation.

Instead I was expecting an error:

[MyTable] failed because [BillingMode] is [undefined] and the permitted value is [PAY_PER_REQUEST]

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

I wanted to propose a change on how the rule is being evaluated by allowing to specify strict matching attributes against the rules.

cfn-guard check --strict -r rule.ruleset -t template.yml 

Optionally this should be enabled per ruleset file by specifying the mode as first instruction of ruleset

let mode = "strict" // or similar to JS `use strict`

or through alternative syntax.

Screenshots
If applicable, add screenshots to help explain your problem.

Operating System:
MacOS

OS Version
10.15.7

Additional context
Add any other context about the problem here.

@jmnarloch jmnarloch added the bug Something isn't working label Nov 9, 2020
@johnttompkins
Copy link
Contributor

A bit confused on this. We currently expose the --strict-checks flag as documented in the README. Does using --strict-checks not work?

@PatMyron PatMyron changed the title [BUG] Checks are lazy evaluated --strict in ruleset itself Nov 12, 2020
@PatMyron
Copy link
Contributor

PatMyron commented Nov 12, 2020

A bit confused on this. We currently expose the --strict-checks flag as documented in the README. Does using --strict-checks not work?

Think this is the main ask that doesn't already exist if I understand correctly:
Optionally this should be enabled per ruleset file by specifying the mode

@PatMyron PatMyron changed the title --strict in ruleset itself --strict-checks in ruleset itself Nov 12, 2020
@rahulgarg05 rahulgarg05 added enhancement New feature or request and removed bug Something isn't working labels Dec 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs-research
Projects
None yet
Development

No branches or pull requests

5 participants