Allow Capabilities to be set through Configuration

[johanfylling]

The http.send() and net.lookup_ip_addr() built-in functions can be allow-listed by host through the allow_net Capabilities param. This feature is, however, limited to the eval command. If capabilities could also be set through configuration, the above feature would also apply to the run command and integration through the SDK.

[srenatus]

I've been wondering if this would be an inline capabilities block, or a reference to some json file on disk. While I first thought that the latter was more convenient, having the content in the config as-is would allow for configuring it with discovery bundles, I think...? So that would be easier to manage in some use cases... 🤔

[johanfylling]

I was imagining the former: an inline capabilities block.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[charlieegan3]

A common use case is default list - http.send - net.lookup_ip_addr(), the JSON representation of this is still quite large, certainly to include in an OPA config file (less of an issue in a discovery bundle of course).

In Regal, we have a plus and minus 'system': StyraInc/regal#212 which I think has some merit, when combined with a default list, and the option to load from disk.

What if we used something similar in OPA? I'm less sure that plus makes sense in OPA core but I guess people could be including additional built-ins in a fork? minus seems to fit at least.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.