Call another rego policy with changing input

[KellyZhou35]

Hi,

I'm pretty new to OPA and rego language, recently I'm working on creating policies to evaluation if a user have access to certain data in our system.

I met following question: how can I call another rego policy with changing input?

For example:
Helper function:

package helper

import input

headers = {
    "Content-Type": "application/json",
    "Accept": "application/json"
}


allow_access := {id : a |
    id:= input.data[_].id
    a = http.send({"method": "GET", "url": sprintf("https://permission-check-url/%s/%s", [ id, input.operation ]), "headers": headers,}).status_code == 200
}

Main evaluation policy:

package evaluation

import input


records[response] {    
    id := input.records[_].id
    errors := [r | e := check_errors[_]
                   e.id == id
                   r := e.reason]

    response := {
        "id" : id,
        "errors" : errors
    }
}

// here, I need to modify the data id a little bit, but in helper policy, how can I use the modified data id as input rather than the original input data id
permissionSet = helper.allow_access 

check_errors[{"id": id, "reason": "you don't have proper access"}] {
    input.operation == ["view", "delete"][_]
    permissionSet := permissionCheck("read")
    id := input.records[x].id
    permissionSet[id] != true
}

and my evaluation call would be http://localhost:8181/v1/policies/evaluation

Currently I'm trying to put helper policy as a function in evalution policy but I don't think this is extendable as putting them in separate rego files.

Any suggestion would be appreciated, thanks!

[anderseknert]

Hi there! You can depend on rules from other policies either by importing them. If you want to modify the input variable in the scope of that evaluation, you may use the with keyword for that:

import data.helper

permissionSet := helper.allow_access with input as {"id": "foobar"}

# or keep the original input while modifying only some attributes

permissionSet := helper.allow_access with input.id as "foo" with input.bar as "baz"

Btw, there's no need to import input — it's always globally available.

[KellyZhou35]

Sure, so my helper policies are as following:

associates.rego:

package associates

urlTemplate = "https://host/api/v1/records/%s/associations?type=parent&query-level=1"
records = {x | x := input.records[_].id }
urls = {u | u := sprintf(urlTemplate,[ records[_] ])}

headers = {
    "Content-Type": "application/json",
    "Authorization": input.token,
    "Accept": "application/json"
}

response_map := { id:resp | id := records[x]
                            resp := http.send({"method": "GET", "url": sprintf(urlTemplate,[ id ]), "headers": headers})
}

not_found_record := [r| r = records[x]
                        response_map[r].status_code == 404
]

no_relationship := [n | n = records[x]
                        response_map[n].status_code == 200
                        count(response_map[n].body.associates) == 0
]

valid_record_ids := [v | v = records[x]
                    response_map[v].status_code == 200
                    count(response_map[v].body.associates) > 0
]

And tag.rego:

package tag

headers = {
    "Content-Type": "application/json",
    "Authorization": input.token,
    "Accept": "application/json"
}

tag_response := {id : a |
    id:= input.records[_].id
    a = http.send({"method": "GET", "url": sprintf("https://host/api/v1/tags/%s/%s", [ id, input.operation ]), "headers": headers})
}

inherit_records := [r | 
    r := input.records[_].id
    orbit_response[r].body.tags.Inherit == "True"
]

no_inherit_records := [r | 
    r := input.records[_].id
    orbit_response[r].body.tags.Inherit != "True"
]

And my entry policy is as following:

package authz


import data.tag as tag
import data.associates as relationship

no_inherit_records := tag.no_inherit_records
inherit_records := tag.inherit_records

temp_records := [{"id": recordId}] {
    recordId := inherit_records[x]
}

updated_input := {
    "token": input.token, 
    "operation": "view", 
    "records": temp_records
}

parents := p if {
    p := replationship.valid_ouput with input as updated_input
}

So basically what I want is to use the output of tag.rego as the input of associates.rego, but I don't know why it doesn't work out.

Thanks a lot for your help :)

[anderseknert]

replationship is a typo :) should be relationship. you'll also need to import future.keywords.if.

Last, in the tag package, you're referring to an undefined orbit_response ... did you mean tag_response?

[KellyZhou35]

after I fix all the typos it works!! thank you so much for the patience and help, really appreciate it!

[thomasmckay]

Apologies for jumping in here unannounced 😃 but what is the recommended devel/debug flow here that could have assisted self-help earlier? vscode? playground? linter?

[anderseknert]

No apology needed, @thomasmckay 🙂

In the case of mistyping an identifier, like in "replationship" above, commands like opa check or opa eval should tell you that there is no such thing, i.e. "var replationship is unsafe". This can be run from VS Code or the terminal, and I normally set opa check to run on save in VS Code.

When it comes to references in data or input, the general purpose / dynamic nature of Rego however means that OPA normally can't know whether there is something like input.replationship or not — that would fail only at runtime. What you can do is to provide OPA that information at compile time by enhancing the type checker through schemas. JSON schemas allow you to define the expected structure of input or data, and have OPA fail compilation if something referenced isn't valid according to schema. So if e.g. input.replationship isn't in your schema — OPA won't allow the policy to compile.

This has been around for a while, but isn't used nearly as much as I believe it deserves to be. One reason could be that we've required schemas to be provided in separate files. Next release of OPA will allow inlined schemas, which should help with providing at least simple defintiions directly in policy.

Since you asked I noticed that the new inline schema option is missing in the docs on type checking. I've created an issue to fix that.