Extending OPA

[Ronnie-personal]

I'm looking at https://www.openpolicyagent.org/docs/latest/extensions/, the examples are written in go, so that's the only supported language?

Is this feature common and being used by many enterprise grade applications?

Thank you!

[anderseknert]

Hi Ronnie! Yes, since OPA itself is written in Go, that's what you'll need to use in order to extend it. Since OPA also comes with a Wasm runtime, we've talked about allowing extensions compiled to Wasm at some point in the future, which would allow you to write extensions in any language that compiles to Wasm. But we're not there yet.

I would not say that I believe it's common to extend OPA with custom functionality in enterprise apps. Is there any particular plugin or builtin function you find missing?

[Ronnie-personal]

Hi @anderseknert
1)
In this document “https://www.openpolicyagent.org/docs/latest/external-data/#option-5-pull-data-during-evaluation”
It says 'The ‘http.send’ built-in functions do not implement any retry logic.'
Does it mean that it may not be suitable for production workloads?
So I need to write my own custom built-in function and shouldn't use 'http.send'?

2. Do you use the custom built-in function to query the data in runtime?
   This is an open source project example https://github.com/aserto-dev/topaz/tree/main/builtins/edge/ds

3. in the OPA document https://www.openpolicyagent.org/docs/latest/extensions/#custom-built-in-functions-in-go
   It says ‘Custom built-in functions must not be used for effecting changes in external systems as OPA does not guarantee that the statement will be executed due to automatic performance optimizations that are applied during policy evaluation.’
   Does it mean that we can not use the custom built-in functions to retrieve data at runtime?

I'm joining the office hour, will discuss more on these questions.

Thank you!

[srenatus]

Chiming in here for a clarification on (3.):

Does it mean that we can not use the custom built-in functions to retrieve data at runtime?

No, it doesn't mean that. It means that you should not use custom built-in functions to do logging, or to execute any background tasks or something like that. If you use one to retrieve data, you're going to depend on that data for your policy decision, so the builtin call will not be optimized away.

[anderseknert]

Hi again Ronnie! There are plenty of production deployments using http.send in their policies. Retry logic would add a significant slowdown to evaluation, and I think most would rather have the evaluation fail quickly than wait for that. The logic could of course be implemented in the client calling OPA if required.

I'm not sure about your second point. Is that a question to me?

[Ronnie-personal]

Thank you all for the prompt reply!

One last question if you don't mind.

Does OPA have a setting for the maximum policy evaluation time?

[anderseknert]

You can provide a --timeout to e.g. opa eval. If you're running OPA as a server, you'd normally just set a timeout value on the HTTP client. OPA will stop evaluation on client disconnect.

[Ronnie-personal]

Excellent! Thank you all for the great help!