Open paulbailey opened 4 months ago
A more generic solution is needed. I have a terraform wrapper that exposes the variable $TERRAFORM_JSON_PLAN
as the filepath to the json version of the plan so that any third party tool can be used as part of a list:
pre_apply_checks: {
enabled: true
commands: [
{
name: "tf-summarize"
command: ["tf-summarize", "-md", "$TERRAFORM_JSON_PLAN"]
},
{
name: "conftest"
command: ["conftest", "test", "--all-namespaces", "-p", "$CONFIG_ROOT/shared-policies", "-p", "policy", "$TERRAFORM_JSON_PLAN"]
files: ["policy/*.rego", "$CONFIG_ROOT/shared-policies/*.rego"]
},
]
}
Community Note
Describe the user story As a cloud engineer, I am asked to ensure that infrastructure I deploy is compliant to a set of standards defined by a security team. Often, these standards are enforced by a scanning process against deployed infrastructure, but a large number of these could be caught by static analysis. I'd like to be able to test and enforce these policies using the mechanism built in to Atlantis, to avoid issues prior to deployment.
Describe the solution you'd like I'd like the ability to specific files that specific rules run against. An additional key under
policy_sets
, perhapsfilespec
? If that key is unset, then the policy set runs against the $SHOWFILE, as it does now. If the value is set, then it is passed to conftest as the input file(s). The rest of the mechanism would remain unchanged, with the PR comment populated in exactly the same way as it is now.Describe the drawbacks of your solution Adding another key adds additional complexity, and the extra files to be checked (at least in my circumstances) would need to be generated by a custom workflow, running the risk that the policy set may fail because of a related failure earlier in the process.
Describe alternatives you've considered I have tried to do this with custom workflows, but it isn't as clean, for a number of reasons. Firstly, I have to override the default conftest mechanism, and although that is documented, it doesn't work as well as separate
policy_sets
do. It also feels as though I am swimming against the tide, overriding default functionality that I would much rather use.I have marked myself as willing to implement this feature, and I am prepared to try to pull together a PR, but this is by far the largest Go codebase I have worked on, so I can make no guarantees about the quality of the code!