feat: basic support OPA plugin

[bzp2010]

What this PR does / why we need it:

Add OPA plugin to support API access control using OPA services.
implement #5714

Pre-submission checklist:

• Did you explain what problem does this PR solve? Or what new features have been added?
• Have you added corresponding test cases?
• Have you modified the corresponding document?
• Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

[anderseknert]

Nice! I can't comment on the Lua bits, but what I read looks sensible. Some random thoughts:

• I would probably just let the user configure the full OPA URL rather than separating host, package and decision. In some cases you'll actually query a whole package, which is fine for OPA.
• The policy example (and from what I understand, the Lua code) only deals with boolean decisions. Maybe good to keep it simple, but could also be useful to allow OPA to return for example a reason for denying a request, and surface that to the caller.
• I don't see much in terms of documentation. Will that be added in a later PR?

But all things considered, great work on this! 👏

[bzp2010]

Hi, @anderseknert. Glad to see your comments.

I would probably just let the user configure the full OPA URL rather than separating host, package and decision. In some cases you'll actually query a whole package, which is fine for OPA.

Do you mean to merge host, package, decision together and use a single field (eg. url)?

The policy example (and from what I understand, the Lua code) only deals with boolean decisions. Maybe good to keep it simple, but could also be useful to allow OPA to return for example a reason for denying a request, and surface that to the caller. I don't see much in terms of documentation. Will that be added in a later PR?

Features such as custom response codes, response headers and error causes will be added later in the PR. It will basically follow the roadmap section in #5714 to implement it.

[anderseknert]

Do you mean to merge host, package, decision together and use a single field (eg. url)?

Yeah. Either way is fine though :)

Features such as custom response codes, response headers and error causes will be added later in the PR. It will basically follow the roadmap section in #5714 to implement it.

Oh, nice! I had missed the roadmap section. Thanks for bringing that to my attention! Sounds like a good plan 👍

[bzp2010]

Ok, In that case, I would keeping the current way of combining URLs, which seems to provide better flexibility. XD

[anderseknert]

Ok, In that case, I would keeping the current way of combining URLs, which seems to provide better flexibility. XD

I'm not sure that it's more flexible. It seems that currently all the fields are required to build the URL:

required = {"host", "package", "decision"}

But while not super common, it is perfectly legitimate to query OPA for only a package, like:

http://localhost:8181/v1/data/policy

When OPA is queried on the package level, it will evaluate all the rules under that package and return the result. So a policy that looks like the below:

package policy

default allow = false

allow {
    input.user.roles[_] == "admin"
}

reason = "User needs to be admin" {
    not allow
}

When queried at http://localhost:8181/v1/data/policy, would respond with the result from evaluating both rules:

{
    "allow": false,
    "reason": "User needs to be admin"
}

In this case, we don't query a rule (or decision as it's called in this code) directly, but rather all the rules in the package.

[bzp2010]

Oh, I see, I will change it later. I don't know OPA very well, thank you for pointing out my problem.

[bzp2010]

ping @tokers @tzssangglass @shuaijinchao PTAL, thanks

[moonming]

@bzp2010 please add OPA into the README, thanks.