Rego Schemas not enforcing access in a function

[danieldebeer-dd]

Hi everyone!
I’m working on a project in which I need strict adherence to a JSON schema for the input while testing Rego policies. I’ve noticed, however, that the schema will not enforce adherence when a variable is passed to a function during an opa eval. In fact, it seems to forget entirely that an object came from input when it is passed to a function.
For reference, this is on OPA CLI version 0.46.1.

If I have for example a policy like this (note the typo on the final line, input.othe should read input.other:
package test

import future.keywords.if

test_func(var) = "no" if {
    var.foo
} else = "yes" {
    var.bar
}

test = test_func(input.othe)

and an input like this:

{
  "other": {
    "foo": false,
    "bar": true
  }
}

and a schema like this:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "other": {
      "type": "object",
      "properties": {
        "foo": {
          "type": "boolean"
        },
        "bar": {
          "type": "boolean"
        }
      },
      "required": [
        "foo",
        "bar"
      ]
    }
  },
  "required": [
    "other"
  ]
}

Then, if I run opa eval data.test --data test.rego --input input.json --schema schema.json, we will of course have an error letting me know that I have a typo on other:

...
"message": "undefined ref: input.othe",

However, this does not extend to foo and bar, although it is clear that they also come from input. If I change the policy to look like this (note the typo, should be var.bar not var.ba):
package test

import future.keywords.if

test_func(var) = "no" if {
    var.foo
} else = "yes" {
    var.ba
}

test = test_func(input.other)

Then I get no error when running with the schema. I would have to explicitly try to access input.var.ba to get the error, but passing input.other to a function makes it lose entirely its JSON schema access enforcement.

The same goes for the input – If i change the input to look like something other than the schema (e.g. changing foo for fo), OPA doesn’t complain at all.

Is this a bug, or there a way around this? It seems to be a major drawback to using schemas, because you often want strict adherence no matter where in the policy resources are accessed, and it would be very useful to be able to enforce the format of input as well.

Thanks for the help, and please let me know if you need any more details.

[srenatus]

Thanks for the detailed report.

As per wether this is a bug or not -- Let's take the perspective of the type of your entities. What's the type of test_func? It takes an argument var, and returns one of two strings based on whether var.foo or var.bar is defined. And as far as the typing of the function goes, that's it. The type checker doesn't know that the function is only ever used on that schema-constrained input. As such, it cannot make the assumption that var has a specific type. After all, the function could be used in other places, with other inputs.

However, I get that you'd like schema support for catching typos in functions, too. But I think we should then look into providing the compiler with the information about the schema of var -- which would be some subschema for the schema for input. Alternatively, we could attempt to let the user tell the compiler that the function calls in this one file are the only ones that matter -- so there's never going to be outside callers etc; so the type checker could be stricter... I'm making this up on the spot, but that's the knowledge gap the compiler/type-checker has right now, I think.

[anderseknert]

Allowing schema annotations on functions to provide type information on arguments, and return value, would indeed be a nice addition.