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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow policy checks to be run against files other than the JSON version of the Terraform plan #4470

Open
1 task done
paulbailey opened this issue Apr 24, 2024 · 0 comments
Labels
feature New functionality/enhancement

Comments

@paulbailey
Copy link

Community Note

  • Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.

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, perhaps filespec? 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!

@paulbailey paulbailey added the feature New functionality/enhancement label Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement
Projects
None yet
Development

No branches or pull requests

1 participant