You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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!
The text was updated successfully, but these errors were encountered: