[Enhancement] Introduce Parameter Inputs for checking the CF scripts

[konkerama]

Is your feature request related to a problem? Please describe. In its current form, cfn-guard checks the Cloudformation script without any input.

Example, Lets say I have a Cloudformation script similar to the following (simplified version)

Parameters:
  RDSEncryption:
    Type: String

Resources:
  RDSPostgressDB:
    Type: AWS::RDS::DBInstance
    Properties: 
      StorageEncrypted: !Ref RDSEncryption

I want to create an RDS Database and I have a CF parameter input for encryption (true/false). Currently there is no way in cfn-guard to verify that the RDS will be created using encryption. I can only verify that the StorageEncrypted will have the value "RDSEncryption" (please correct me if I'm wrong)

Describe the solution you'd like I would prefer an option to provide a json document with the CF parameter inputs and be able to check the Cloudformation script after all those values have been implemented. The example I gave above would look like:

rules:

AWS::RDS::DBInstance StorageEncrypted == true

input.json:

[
  {
    "ParameterKey": "RDSEncryption",
    "ParameterValue": "true"
  }
]

cfn-guard:

cargo run -- -t rds.yaml -r rules -i input.json

cfn-guard will change the RDSEncryption Rerefence with the input true and will be able to check against that

[nathanataws]

This is a very reasonable use-case. We're kicking this kind of thing around already. Let's use this issue to track the work.

[rajddas]

Guys is there any ETA on this feature release?

[nathanataws]

No ETA yet but still a high priority.

[PatMyron]

raises larger questions of CloudFormation template syntax: dynamic references, intrinsic functions, psuedoparameters, parameters, mappings, conditions, transforms, etc.: https://github.com/aws-cloudformation/cloudformation-guard/issues/480

[konkerama]

@PatMyron indeed supporting all these "dynamic" features of Cloudformation will be necessary for a tool like this. From my point of view, the Input Parameter support has the highest priority of those features and its the bare minimum functionality we require to include it as a compliance mechanism in our CICD Pipelines

[rajddas]

Also it would be great if we allow the parameter json files needed for CodePipeline Cloudformation Action. Like this :

{
    "Parameters" : {
        "Owner": "ABC",
        "CostCenter": "1234567890"
    }
}

[rajddas]

Any update on this feature request?

[n1t1nv3rma]

Any update on this? Basically we would like CFN-guard to resolve the "Ref" from "Parameters" and allow us to validate the input value. W/o this feature, I don't see major uptake on this. Thanks

[shreyasmm]

we use taskcat in CI/CD Pipelines for testing Cloudformation templates, we have written a lot of taskcat files for templates with different test cases like eg enable/disable encryption, encryption with kms/user manged keys. it would be good if we reuse/provide those taskcat files as input to cfn-guard, thanks https://github.com/aws-quickstart/taskcat

[el-veee]

I also see this feature as essential, both for testing new templates and running validation checks on pre-existing templates.

Parameters are essential in all but the simplest of cloudformation templates, and therefore cloudformation-guard MUST support it to be usable on a large scale.

Perhaps CLI args can be passed in for each parameter, and cfn guard creates a new template with the previously-parameterized values now hardcoded into the template. CFN guard then runs checks on that template?

Where parameters support have default values, CFN guard will default to those values unless overridden? This would reduce the need to specify many parameter values for each test

[sriram9707]

is there any update on this please. Eagerly waiting for utilizing it.

[sriram9707]

is this something handled in release 2.0 ?

[dchakrav-github]

@sriram9707 @lachlan-vass @konkerama Currently this would require re-implementing the entire CFN server-side resolution semantics again in Guard. Would it be okay if we provided a separate binary/library that does CFN resolution semantics given a template and parameter file in JSON/YAML (complete support for intrinsic resolutions, will not have support for Macros/Transforms, however initially) and have that piped to guard. E.g.

cfn-resolve -t template -p parameters.yaml | cfn-guard -r rules 

[el-veee]

@dchakrav-github

The usage of what you're proposing still looks quite simple. I'm fine with it

[sriram9707]

is there any ETA on this ? @dchakrav-github

[sriram9707]

@dchakrav-github @PatMyron any ETA for this ?. we have been trying to leverage cfn guard thorugh our pipeline which will have template and respective parameters file. or is there any workaround for this ?

[razcloud]

We do not have an ETA on this as of today; however, we are discussing internally to determine how best to approach this.

[fabiodouek]

Was there any progress on this, or same position as one year ago?

[razcloud]

Hi @fabiodouek This item is currently in our backlog. We do not have an estimate on when this feature will be delivered.

[sha-aegon]

Is the above issue resolved on latest Cloud Formation Guard version i.e 2.1.3 as it is basic use case in most of the cfn templates ?

[joshfried-aws]

@sha-aegon Hi, this is still in our backlog. We do not have an estimate for when this will be implemented/released.

Thanks

[bhavinbn]

This is one of the most critical feature to use this tool for us as we have multiple environments with common cfn and we use parameters. I think this would be the case for most of the techies who uses cloudformation. Can you pls share if there is any progress on this issue and any ETA for the same as it would be much needed.

[tsz662]

It's 2024 already. Any progress? Lack of Input Parameter support is holding us back from using cfn-guard...

[dhutchison]

This limited our adoption of guard as we had wanted to check initially a lot around naming (which relied on parameters).

What we ended up doing was move to Python unit tests for this using cloud-radar. (Which as a disclaimer, I’ve contributed features towards for dynamic reference support and reusable checks)