Guard offers a policy-as-code domain-specific language (DSL) to write rules and validate JSON- and YAML-formatted data such as CloudFormation Templates, K8s configurations, and Terraform JSON plans/configurations against those rules. Take this survey to provide feedback about cfn-guard: https://amazonmr.au1.qualtrics.com/jfe/form/SV_bpyzpfoYGGuuUl0
Apache License 2.0
1.3k
stars
180
forks
source link
[GENERAL ISSUE] - cfn-guard-lambda response parsing seems like a bit much #574
Describe the issue
The cfn-guard-lambda response is very verbose and seems to require a good chunk of knowledge about the inner workings of the tool to parse and that feels cumbersome enough that I am hoping to double check that I am using the available tools appropriately.
To avoid the xy problem i'll describe the general problem I'm trying to solve:
we have a lot of small repos that each have their own cfn templates and I was hoping to use cfn-guard to enforce some org wide rules against some resources that may be in the templates.
to run cfn-guard against the myriad of repos i was planning to create a github org wide webhook on PR events that would hit a lambda that would be deployed with the org ruleset and run it against a template (if in the PR diff) via a separate cfn-guard-lambda
the webhook lambda would parse the results and relay them as a github check to the PR
As I'm digging into parsing the nested response of the lambda it feels like i'm going to be recreating a component of what cfn-guard natively already does in order to capture what rules actually failed, with their messages, and where they failed in the template.
The information is all there in the lambda output so I don't think this is a bug or anything. I'm half asking for a sanity check that there isn't a way to use the cfn-guard lambda that bubbles up the summary like the cli does and ultimately probably going to ask for a feature request to create that or at least some example code in the docs as a reference point
Describe the issue The cfn-guard-lambda response is very verbose and seems to require a good chunk of knowledge about the inner workings of the tool to parse and that feels cumbersome enough that I am hoping to double check that I am using the available tools appropriately.
To avoid the xy problem i'll describe the general problem I'm trying to solve:
As I'm digging into parsing the nested response of the lambda it feels like i'm going to be recreating a component of what
cfn-guardnatively already does in order to capture what rules actually failed, with their messages, and where they failed in the template.Any examples Output from
cfn-guardcli: cfn-guard-cli.txtOutput from
cfn-guardlambda (same ruleset/template): cfn-guard-lambda.jsonThe information is all there in the lambda output so I don't think this is a bug or anything. I'm half asking for a sanity check that there isn't a way to use the cfn-guard lambda that bubbles up the summary like the cli does and ultimately probably going to ask for a feature request to create that or at least some example code in the docs as a reference point