Skip to main content

See Bundle Format for additional information.

Data Bundle API

Working in much the same way as in OPA, the Bundle API is a functionality of Enterprise OPA which can can periodically download Enterprise OPA formatted bundles from remote HTTP servers.

The following is an example of a simple Enterprise OPA configuration using the Bundle API, note that it's the same as how policy can is fetched:

token: "bGFza2RqZmxha3NkamZsa2Fqc2Rsa2ZqYWtsc2RqZmtramRmYWxkc2tm"

service: acmecorp
resource: somedir/bundle.tar.gz
persist: true
min_delay_seconds: 10
max_delay_seconds: 20

Using this configuration, Enterprise OPA will fetch bundles from using a Bearer token for authentication.

Other advanced features of the Bundle API are explained in detail in the OPA documentation:

Datasource Plugins and Bundles

When using Datasource plugins (like Kafka or HTTP), their respective configured data subtrees are protected in the same way that a bundle's roots are protected: writes to the data path using the REST API will be forbidden.

This also applies when using bundles and data plugins: their respective roots needs to be disjoint. So any bundle used together with data plugins must have a .manifest file that declares its roots.

"roots": ["transform"]

This manifest would be valid for a bundle that declares a message transform in package transform. As long as none of the configured data plugins use the root data.transform, there will be no conflicts.

If a bundle does not declare roots, it owns all of data, and will thus be in conflict with any data plugin: if data cannot be modified, the data plugin is prohibitied from writing to any data subtree.