Add rego policy validation for yaml files while editing yamls or as a static policy validation

[mrgadgil]

Usecase:
Have policy written in rego
Input format : yaml
Run the opa policy engine against the yaml files as linter similar to a schema validator. This would make the policy validation intuitive for vscode users.

I also noticed that the opa evaluate commands so not support yaml and need the file name to be input.json

[charlieegan3]

Hey @mrgadgil, thanks for filing the issue and for stopping by the kiosk at kubecon. I think this feature makes sense. I am unsure how best to implement it, one idea I had would be to add another language server to the extension that could read rego files and use the currently open file as input to the rego policy in the same repo. However, we'd need a means to map input files to the relevant policies.

Can you share some examples of the IBM cloud yamls you're working on and the policies you want to use to 'lint' them?

[anderseknert]

Supporting input.yaml in the Evaluate code lens sounds easy enough! I'll create an issue to do that in Regal.

As for linting JSON/YAML directly in the editor based on policy — that is a neat idea. We'd need a JSON/YAML parser that'd decode not just the data, but did so with location information stored too. I'm not aware of many libraries that do that, but if others do, I'd love to learn about them! Some background in this issue open-policy-agent/opa#2935

[mrgadgil]

@charlieegan3 Thank you for chatting with me at the booth.
@anderseknert creating a input.yaml seems to be a good starting point. That would first extend support to yaml as input. Is it possible to add a config, where instead of calling the file input.yaml we can use name of choice?
We can try to combine our checks into single multi doc yaml and run the policy check against it.

[anderseknert]

Allowing the name of the input file to be configured would be doable too. I'll look into that.

One thing to keep in mind though is that the purpose of this extension is to help support Rego policy development. It's not really meant to be used as a frontend for running OPA against a number of arbitrary input files and display the results inlined in JSON or YAML files. Don't get me wrong — that would be an absolutely awesome feature! But as @charlieegan3 suggested, one that might be a better fit in a separate extension / language server. OTOH, having a single extension have benefits too, so who knows :)

Regardless of where that would belong, it would certainly be a large effort, and I don't think that's likely to happen in the near future.

[anderseknert]

Support for input.yaml was recently merged in Regal, and will be included in the next v0.30.0 release. I think that's about as far as we're ready to go at this point, so I'll close this for the time being. If anyone is interested in picking up the "OPA linting JSON and YAML directly in the editor" idea and do something with that, we'd love to talk!

[anderseknert]

Regal PR here: StyraInc/regal#1269

[mrgadgil]

Thank you @anderseknert for the fix. Appreciate the quick turn around. I will adopt it as part of development and evaluation process.