Digest policy as code from a targeted github repository

[cnorling]

Is your feature request related to a problem? Please describe. Handling policy as code in datree's current state requires datree to be ran anytime a change to a policy is added or implemented.

Describe the solution you'd like Instead of running datree as a process, it would be nice if datree could be configured to just read policies.yaml from a repo.

Describe alternatives you've considered The alternative would be manually defining our own CI pipeline to run datree publish on main whenever changes are pulled in. The thing I don't like about this solution is that a pipeline needs to be defined and then maintained. Reading from source would be a much more elegant and preferred solution.

[eyarz]

We thought about supporting this option, but there is one big challenge: what will happen when a user is providing a link to an invalid policies file?

Because the policies file won't necessarily go through a validation process (datree publish), it can cause major pain to the user experience because it will stop\block all the workflows relying on Datree's policy check.

So, defining policy-as-code in its own CI pipeline creates (a little 😉) more work, but it is worth it because your policies, and the workflows that are relying on them, will be more stable :)

[cnorling]

We thought about supporting this option, but there is one big challenge: what will happen when a user is providing a link to an invalid policies file?

This was a problem space I honestly didn't put much thought into until you mentioned it. Would it be better for something like a linter to catch invalid policy files? It would be a pain if a merge caused cascading build failures, but I feel like there are options for gracefully handling an invalid policy file that aren't show stoppers. This issue is almost parallel to what products like ArgoCD face where the strategy for remediation is to use the last known good state until someone can remediate the defect.

I'm glad I wasn't the first person to think of defining these policies in CI. Would it be worth documenting creating your own pipeline as an option for managing policies as code? I couldn't find any documents on hub.datree.io that condoned the practice.

[eyarz]

This issue is almost parallel to what products like ArgoCD face where the strategy for remediation is to use the last known good state until someone can remediate the defect.

And how the user knows that his last ArgoCD config wasn't applied?

Yes, I agree, this is definitely something that we need to add to our docs. Where do you think will be the best place (on the docs) to mention that?

[eyarz]

@salineselin following your feedback, I opened an issue to improve our docs (#295). If you have any suggestions for the docs, feel free to share them there.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.