Anders Eknert

OK, so having thought about this for some time — instead of moving this to the `custom` category, where likely few will notice or use this.. How about we change...

I don't think it's so much about features per se as it is having a consistent experience when working with Rego for Gatekeeper policies vs Rego for other projects. Also,...

Understood! And we'll be happy to help support you in that effort 🙂 The complexity of the user experience is IMHO made *worse* by only supporting a syntax of Rego...

v1 versions of all the bundled policies available in this PR: https://github.com/open-policy-agent/gatekeeper-library/pull/639 I hope we can get them integrated as an option at some point :)

@jagmohan-nanaware when you provide data to OPA like that, it's not provided as input, but as part of the `data` document (which is populated by both policies and JSON data)....

@jagmohan-nanaware sorry, I spoke too quickly 😅 The data is populated, just not visible by default as the `system` root is reserved for internal functions. You _can_ still see it...

Thanks for reporting that! It's interesting that both `yaml.is_valid` _and_ `yaml.unmarshal` works. I'm guessing it's the YAML library trying to be lenient?

If OPA has a built-in function called `yaml.is_valid` that returns `true` for YAML that _isn't_ valid, that's a bug in OPA regardless of the origin of the bug. I too...

Thanks, Ash 👍

No. You can perhaps chime in on the thread for the upstream issue that was closed without responding to later comments: https://github.com/kubernetes-sigs/yaml/issues/112