Skip to main content
note

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:

services:
  acmecorp:
    url: https://example.com/service/v1
    credentials:
      bearer:
        token: "bGFza2RqZmxha3NkamZsa2Fqc2Rsa2ZqYWtsc2RqZmtramRmYWxkc2tm"

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

Using this configuration, Enterprise OPA will fetch bundles from https://example.com/service/v1/somedir/bundle.tar.gz 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 prohibited from writing to any data subtree.