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

[Enhancement] Introduce Parameter Inputs for checking the CF scripts #39

Open
konkerama opened this issue Jul 9, 2020 · 24 comments
Open
Labels
enhancement New feature or request needs-research

Comments

@konkerama
Copy link

konkerama commented Jul 9, 2020

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

@konkerama konkerama added the enhancement New feature or request label Jul 9, 2020
@nathanataws
Copy link
Contributor

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
Copy link

rajddas commented Jul 17, 2020

Guys is there any ETA on this feature release?

@nathanataws
Copy link
Contributor

No ETA yet but still a high priority.

@PatMyron
Copy link
Contributor

PatMyron commented Sep 17, 2020

raises larger questions of CloudFormation template syntax: dynamic references, intrinsic functions, psuedoparameters, parameters, mappings, conditions, transforms, etc.: #480

@konkerama
Copy link
Author

@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
Copy link

rajddas commented Oct 2, 2020

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
Copy link

rajddas commented Oct 16, 2020

Any update on this feature request?

@n1t1nv3rma
Copy link

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
Copy link

shreyasmm commented Nov 18, 2020

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
Copy link

el-veee commented Jan 8, 2021

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
Copy link

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

@PatMyron PatMyron pinned this issue May 8, 2021
priyap286 added a commit that referenced this issue May 17, 2021
This commit introduced an unwanted behavior with the some keyword while
fixing for [*] clauses to fail when empty.

This reverts commit 611de1f.
@sriram9707
Copy link

is this something handled in release 2.0 ?

@dchakrav-github
Copy link
Contributor

@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
Copy link

el-veee commented May 21, 2021

@dchakrav-github

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

@sriram9707
Copy link

is there any ETA on this ? @dchakrav-github

@sriram9707
Copy link

@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
Copy link
Contributor

razcloud commented May 2, 2022

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

@fabiodouek
Copy link

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

@razcloud
Copy link
Contributor

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

@sha-aegon
Copy link

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
Copy link
Contributor

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

Thanks

@bhavinbn
Copy link

bhavinbn commented May 28, 2024

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
Copy link

tsz662 commented Sep 9, 2024

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

@dhutchison
Copy link

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)

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