Policy approval caching

[pseudomorph]

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.

---

• [x] I'd be willing to implement this feature (contributing guide)

Describe the user story

Sometimes TF plans get updated after approval has been given. In some cases, such changes have no bearing on triggered policies. The need to seek additional review/approval slows developer velocity. It would be useful if there was a means to cache and retain approval between plan runs when the triggered policies are the same.

Describe the solution you'd like

I think this can be accomplished by hashing the conftest output and storing the hash in BoltDB or Redis. If the hash generated for the current plan matches with the previous hash, and a server conf parameter has been set (something like --enable-sticky-policy-approvals), previous approval counts should be retained.

Describe the drawbacks of your solution

If rules are not written in such a way as to uniquely identify individual policies, conftest output may appear the same when the nature of the policy violations differ. When rules outputs do not provide specific and unique identifiers, sticky approvals would allow for potential vectors to bypass policies. By placing this feature behind a config parameter and presenting warnings in the documentation, it is up to the end user to determine if their policies meet the criteria to avoid stated risks.

Describe alternatives you've considered

Alternatives would include modifying conftest to provide a unique hash based on rule evaluation traces. I do not think that conftest is in a position for this to be easily done.

[pseudomorph]

Would this be more useful as a global or policyset config? With the latter, approval could be cached or not on individual policy sets.

[pseudomorph]

Since much of the approval logic already exists in and is pulled from the repo config, I think this would be best suited there.