JSON Schema Keywords AllOf and AnyOf in OPA Type Checker
Open Policy Agent (OPA) is an open source engine that unifies policy enforcement across the cloud native stack. This project includes a recent enhancement to its Rego type checker that uses JSON schemas as input during evaluation of policy. This enhancement is achieved through the “opa eval” command and the -s flag to include a schema in the input. The JSON schemas that are provided as input during policy evaluation essentially provide a blueprint for the policy being written, and this allows for easier and more immediate type checking. This provides more precise and informative error messages.
Previous blog posts introduced the type checker with a few limitations, as it does not provide support for many keywords available in the JSON Schema 2019-09 release. For example, this type checker did not provide support for “allOf” and “anyOf” keywords.
allOf vs. anyOf — What’s the Difference?
To understand the meaning of anyOf and allOf, consider entering your mailing address to purchase something online. After entering your address line, you can either specify it with state, city and ZIP code or with country and postcode. For those who are familiar with JSON Schema language, it might look something like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
{ "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "title": "My schema", "properties": { "Address": { "type": "string" }, }, "required": [ "Address" ], "anyOf": [ { "allOf":[ { "type": "object", "properties": { "State": { "type": "string" }, "City": { "type": "string" }, "ZipCode": { "type": "string" } }, }, { "required": [ “State”, “City”, "ZipCode" ] } ] }, { "allOf":[ { "type": "object", "properties": { "County": { "type": "string" }, "PostCode": { "type": "string" } }, }, { "required": [ “County”, "PostCode" ] } ] } ] } |
In other words, after entering your address line, you’re prompted to enter either (state AND city AND ZIP code) or (country AND postcode) (technically, you can enter both options under “anyOf” since it’s an inclusive “or”).
As we can see in the two options to describe your address line, whichever one you choose, you must include all the specified information because of a sub-schema containing the “required” properties in both of the allOf listed schemas. Allowing “anyOf” then adds the flexibility of choosing different mailing address options, and allowing “allOf” ensures security in that all the required information will be there (applicable to this example only).
Support was added to allow for these keywords in OPA’s type checker in the 0.32.0, so users can now include schemas that use these keywords. Let’s suppose you’re the admin of a shopping website and you want to temporarily deny Californian shoppers the ability to order because the current wildfire situation impedes shipping. Thus, you can write an API policy like the following to access user information and identify those visitors who live in California.
|
1 2 3 4 5 |
package shopper.mailingAddress deny { input.States == “California” } |
As humans, we all make mistakes, and the above policy contains a typo that you may or may not have noticed (if you have, good job!). Now with the newly implemented support for “anyOf” and “allOf”, OPA will inform you of the possible error:
|
1 2 3 4 |
input.States ^ have: "States" want (one of): ["City" "County" "PostCode" "State" "ZipCode"] |
Implementation of support for the “allOf” and “anyOf” keywords eliminated a limitation of OPA’s type checker, so now schemas that use these keywords will render more useful error messages during policy creation and evaluation. These keywords are particularly relevant because Kubernetes admission control is one of the important use cases for OPA, and many of Kubernetes’ published schemas use “allOf” and “anyOf.” With this newly implemented support for “allOf” and “anyOf,” OPA is now able to support many of these Kubernetes use cases and enhance both security and flexibility for the API policy written. You can read more about this enhancement in OPA’s documentation page.
What’s Next?
Future work relating to this project will involve implementing support for the many other keywords not currently supported by OPA’s JSON schema Rego type checker (enum, if/then/else, among others). Further, we hope to conduct user surveys with the OPA community to evaluate the effectiveness of the type checker. Let us know what you think!
Links
Note: Other authors of this article were Mandana Vaziri, principal research staff member at IBM, and Ansu Varghese, research software engineer at IBM.
