Partial Evaluation return known values filter

[huntkalio]

https://github.com/orgs/open-policy-agent/discussions/722#discussioncomment-14812556

Short description

When known values and unknown values at the same level，the Partial Evaluation will return filter include known values
opa version:

Version: 1.9.0
Build Commit: c49e670294e45bb3fd76b9e945cf821478a4bbfc
Build Timestamp: 2025-09-26T08:53:51Z
Build Hostname: 
Go Version: go1.25.1
Platform: linux/amd64
Rego Version: v1
WebAssembly: unavailable

Steps To Reproduce

data

{
        "authz": {
                "rbac_roles": {
                        "KafkaFullAccessRole": {
                                "resources": [{
                                        "type": "kafka*",
                                        "name": "*ab*"
                                }],
                                "permissions": ["list", "get", "create", "update", "delete"]
                        }
                },
                "rbac_users": {
                        "test": ["KafkaFullAccessRole"]
                }
        }
}

inut

{
        "input": {
                "userInfo": {
                        "username": "test"
                },
                "operation": "get",
                "resource": {
                        "type": "kafka"
                }
        },
        "unknowns": ["input.resource.name"]
}

package kafka.authz_filter

import data.authz
import rego.v1

default allow := false

allow if {
	rbac_allow
}

current_user := input.userInfo.username
current_groups := input.userInfo.groups
current_operation := input.operation

matches(pat, x) if {
    # constant
    not contains(pat, "*")
    pat == x
}

matches(pat, x) if {
    # *
    pat == "*"
}

matches(pat, x) if {
	 # abc*
	endswith(pat, "*")
	not startswith(pat, "*")
	startswith(x, substring(pat, 0, count(pat)-1))
}

matches(pat, x) if {
	 # *def
	startswith(pat, "*")
	not endswith(pat, "*")
	endswith(x, substring(pat, 1,count(pat)-1))
}

matches(pat, x) if {
	# *hij*
	count(pat) > 1
	startswith(pat, "*")
	endswith(pat, "*")
	contains(x, substring(pat, 1, count(pat)-2))
}

resource_matches(resource_pattern, request_resource) if {
	matches(resource_pattern.type, request_resource.type)
	matches(resource_pattern.name, request_resource.name)
}

rbac_allow if {
	user_roles := authz.rbac_users[current_user]
	some role_name in user_roles
	role_grants_access(role_name)
}

role_grants_access(role_name) if {
	role := authz.rbac_roles[role_name]
	current_operation in role.permissions
	some resource_pattern in role.resources
	resource_matches(resource_pattern, input.resource)
}

decision := {"allow": allow}

curl localhost:8181/v1/compile/kafka/authz_filter/allow -H "Accept: application/vnd.opa.sql.mysql+json"  -d @test/unknownshttpinput.json 
{"result":{"query":"WHERE (resource.type LIKE 'kafka%' AND resource.name LIKE '%ab%')"}}

why sql have 'resource.type LIKE 'kafka%' ' condition, it's not unknowns

Expected behavior

sql don't have 'resource.type LIKE 'kafka%' ' condition,

Additional context

[srenatus]

In summary, the input contains a known input.resource.type, and the unknown is input.resource.name. Somewhere in the current filters translation, we have the assumption that if input.resource.name is unknown, all of input.resource.* is taken to be unknown.

This could be pretty far-reaching, as the examples and demos we've worked with always assumed that you'd just declare your tables (like input.resource) and never specific fields (or columns) of those tables.

The workaround in the linked discussion was to separate both types, use input.req_resource.type for the known parts, and input.resource.name as unknown.

[srenatus]

Another work around would be to use a "short unknown" of input.resource_name and provide a mapping for that which would include the table, like

{
  "resource_name": {
    "$table": "resource",
    "$self": "name"
  }
}

[huntkalio]

When known values and unknown values at the same level，below will also fail: say glob.match is forbidden even though request_resource.type is known values。

resource_matches(resource_pattern, request_resource) if {
	glob.match(resource_pattern.type, [], request_resource.type)
	matches(resource_pattern.name, request_resource.name)
}

[huntkalio]

In summary, the input contains a known input.resource.type, and the unknown is input.resource.name. Somewhere in the current filters translation, we have the assumption that if input.resource.name is unknown, all of input.resource.* is taken to be unknown.

This could be pretty far-reaching, as the examples and demos we've worked with always assumed that you'd just declare your tables (like input.resource) and never specific fields (or columns) of those tables.

The workaround in the linked discussion was to separate both types, use input.req_resource.type for the known parts, and input.resource.name as unknown.

Will same level be supported in the future, or will it be stipulated that they need to be at different levels?

[srenatus]

Huh, interestingly enough, the problem seems to lie in PE itself! When I take your policy and request and all that, and feed it into opa eval -p to check the partial eval results, I found something surprising:

$ jq .input < req.json | opa eval -fpretty -p -u input.resource.name -d data2.json -d policy.rego data.kafka.authz_filter.allow --explain=full -I
┌─────────┬──────────────────────────────────────────┐
│ Query 1 │ startswith(input.resource.type, "kafka") │
│         │ __localcp2__ = input.resource.name       │
└─────────┴──────────────────────────────────────────┘

☝️ This should not have startswith(input.resource.type, "kafka"). ⚡

So the bug seems to be in PE, not in the Filters translation 🔍

[srenatus]

I've found this: #3478. It seems to describe this exact situation, and it's not actually been "fixed" -- I've updated the status accordingly.

I think there's nothing new here, except that the data filtering angle to PE makes this more desirable than it was before. I'll have another look at the offending code, too. We could re-open the old issue, but let's just keep this one for tracking.

[huntkalio]

Okay, I understand. I will avoid using it at same level like this for now.