# Bundles

Many use cases require that OPA reload policy and related data while serving requests. OPA is commonly deployed as a supporting role to applications and other callers, so it's often desirable to be able to update policies quicker than would be possible with a full redeployment. Frequent data updates are another driver for this functionality.

Updated policies and data are loaded on the fly without requiring a restart of OPA. Once the policies and data have been loaded, they are enforced immediately. Policies and data loaded from bundles are accessible via the standard OPA [REST API](/docs/rest-api) to callers.

Bundles provide an alternative to pushing policies into OPA via the REST APIs. By configuring OPA to download bundles from a remote HTTP server, you can ensure that OPA has an up-to-date copy of policies and data required for enforcement at all times in an eventually consistent manner.

By default, the OPA REST APIs will prevent you from modifying policy and data loaded via bundles. If you need to load policy and data from multiple sources, see the section below.

See the [Configuration Reference](/docs/configuration) for configuration details.

## Bundle build

The CLI command [`opa build`](/docs/cli#build) gives you the capability to build your own bundles.

Here is a basic example on how to build a bundle from a folder called `foo`. The bundle will be named by default `bundle.tar.gz`.

example.rego

```
package authzallow if {    input.path == ["users"]    input.method == "POST"}allow if {    input.path == ["users", input.user_id]    input.method == "GET"}
```

```
$ ls foo/example.rego$ opa build -b foo/
```

More, you can optimize the bundle by specifying the `--optimize` or `-O` flag. This does require defining an entrypoint. You can provide an entrypoint using the CLI flag `--entrypoint` or as a [Metadata annotation](https://www.openpolicyagent.org/docs/policy-language#metadata).

```
opa build -b foo/ --optimize=1 --entrypoint authz/allow
```

Finally, you can also sign your bundle with `opa build`.

```
opa build --verification-key /path/to/public_key.pem --signing-key /path/to/private_key.pem --bundle foo/
```

For more information, see the [`opa build` command documentation.](/docs/cli#build)

## Bundle Service API

OPA expects the service to expose an API endpoint that serves bundles. The bundle API should allow clients to download bundles at an arbitrary URL. In combination with a service's `url` path.

```
GET /<service path>/<resource> HTTP/1.1
```

If the bundle exists, the server should respond with an HTTP 200 OK status followed by a gzipped tarball in the message body.

```
HTTP/1.1 200 OKContent-Type: application/gzip
```

Enable bundle downloading via configuration. For example:

```
services:- name: 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    signing:      keyid: my_global_key      scope: readkeys:  my_global_key:    algorithm: RS256    key: |      -----BEGIN PUBLIC KEY-----      MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...      -----END PUBLIC KEY-----
```

See [Configuration - Keys](/docs/configuration#keys) for details on key configuration.

Using this configuration, OPA will fetch bundles from `https://example.com/service/v1/somedir/bundle.tar.gz`.

The URL is constructed as follows:

```
https://example.com/service/v1/somedir/bundle.tar.gz^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^services[0].url                resource
```

If the `bundles[_].resource` field is not defined, the value defaults to `bundles/<name>` where the `name` is the key value in the configuration. For the example above this is `authz` and would default to `bundles/authz`.

Bundle names can have any valid YAML characters in them, including `/`. This can be useful when relying on default `resource` behavior with a name like `authz/bundle.tar.gz` which results in a `resource` of `bundles/authz/bundle.tar.gz`.

OPA can optionally persist activated bundles to disk for recovery purposes. To enable persistence, set the `bundles[_].persist` field to `true`. When bundle persistence is enabled, OPA will attempt to read the bundle from disk on startup. This allows OPA to start with the most recently activated bundle in case OPA cannot communicate with the bundle server. OPA will try to load and activate persisted bundles on a best-effort basis. Any errors encountered during the process will be surfaced in the bundle's status update. When communication between OPA and the bundle server is restored, the latest bundle is downloaded, activated, and persisted.

info

By default, bundles are persisted under the current working directory of the OPA process (e.g., `./.opa/bundles/<bundle-name>/bundle.tar.gz`).

The optional `bundles[_].signing` field can be used to specify the `keyid` and `scope` that should be used for verifying the signature of the bundle. See [this](#signing) section for details.

See the following section for details on the bundle file format.

### Caching

Services implementing the Bundle Service API should set the HTTP `Etag` header in bundle responses to identify the revision of the bundle. OPA will include the `Etag` value in the `If-None-Match` header of bundle requests. Services can check the `If-None-Match` header and reply with HTTP `304 Not Modified` if the bundle has not changed since the last update.

When a bundle service is backed by replicas that update at different times, a request can be answered by a replica that still has an older bundle, which OPA would then activate. Setting `bundles[_].polling.superseded_etag_ttl_seconds` makes OPA send the `Etag` values of bundles it replaced within that time in addition to the current one, as a comma-separated `If-None-Match` list. A server that treats the list as specified in [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#field.if-none-match) replies `304 Not Modified` if any of them matches, so the older bundle is not served.

warning

The bundle service must support multiple values in `If-None-Match`. A service comparing the header to a single `Etag` value will never reply `304` and OPA will download the bundle on every poll.

A rollback to a bundle that was replaced less than `superseded_etag_ttl_seconds` ago is not served until the time has passed.

### HTTP Long Polling

With the periodic bundle downloading (i.e. `short polling`) technique, OPA sends regular requests to the remote HTTP server to pull any available bundle. If there is no new bundle, the server responds with a `304 Not Modified` response. The polling frequency depends on the latency that the client can tolerate in retrieving updated information from the server. A drawback of this method is that if the acceptable latency is low, then the polling frequency could add unnecessary burden on the server and/or network.

[HTTP Long Polling](https://datatracker.ietf.org/doc/html/rfc6202#section-2) helps to minimize server/network resource usage and also reduces the delay in delivery of updates to the client. When OPA sends a long poll request to the server, it defers its response until an update is available or timeout has occurred. In case of a timeout, the server responds with a `304 Not Modified` response.

The below configuration shows how to enable bundle downloading via `long polling`:

```
services:- name: acmecorp  url: https://example.com/service/v1  credentials:    bearer:      token: "bGFza2RqZmxha3NkamZsa2Fqc2Rsa2ZqYWtsc2RqZmtramRmYWxkc2tm"bundles:  authz:    service: acmecorp    resource: somedir/bundle.tar.gz    persist: true    polling:      long_polling_timeout_seconds: 10    signing:      keyid: my_global_key      scope: read
```

With the above configuration, OPA sends a long poll request to the server with a timeout set to `10` seconds. If the server supports `long polling`, OPA expects the server to set the `Content-Type` header to `application/vnd.openpolicyagent.bundles`. If the server does not support `long polling`, OPA will fallback to the regular periodic polling.

## Bundle File Format

Bundle files are gzipped tarballs (`.tar.gz`) that contain policies and/or data.

Policy files are Rego source files with the `.rego` extension and will be available within Rego modules based on their package's path, e.g. `package example.authz` is available at `data.example.authz` in the [`data` Document](/docs/philosophy#the-opa-document-model).

The data files within the bundle can be organized hierarchically into directories inside the tarball. The hierarchical organization indicates to OPA where to load the data files into the `data` Document - similar to how Rego files can control their location using the package path. This functionality can be useful when:

*   Deploying larger bundles with policy for different callers and use cases.
*   Creating bundles where different teams manage different parts of the bundle. For example, some shared policy is to be loaded alongside some application specific policy and data.
*   When some parts of the data are to be updated more frequently than others, e.g. using [Delta Bundles](#delta-bundles).

You can list the content of a bundle with `tar`:

```
$ tar tzf bundle.tar.gz.manifestrolesroles/bindingsroles/bindings/data.jsonroles/permissionsroles/permissions/data.jsonhttphttp/examplehttp/example/authzhttp/example/authz/authz.rego
```

In this example, the bundle contains one policy file (`authz.rego`) and two data files (`roles/bindings/data.json` and `roles/permissions/data.json`). A data file in the root of the bundle will be loaded into the `data` Document at the root. For example, the `foo` key is inserted at the root of the `data` document:

```
$ tree bundlebundle└── data.json1 directory, 1 file$ cat bundle/data.json{ "foo": true }$ opa eval -b bundle/ data.foo --format=rawtrue
```

The bundle may also contain an optional Wasm binary file (`policy.wasm`). OPA stores the WebAssembly compiled version of all the Rego policy files within the bundle in `policy.wasm` when building with `-t wasm`:

```
$ cat -p bundle/http/example/authz/authz.regopackage http.example.authzallow := true$ opa build -t wasm -e http/example/authz/allow bundle$ tar tzf bundle.tar.gz/data.json/bundle/http/example/authz/authz.rego/policy.wasm/.manifest$ opa eval -b bundle.tar.gz data --format=raw{"http":{"example":{"authz":{"allow":true}}}}
```

Bundle files may contain an optional `.manifest` file that stores bundle metadata. The file should contain a JSON serialized object, with the following fields:

*   `revision` - If the bundle service is capable of serving different revisions of the same bundle, the service should include a top-level `revision` field containing a `string` value that identifies the bundle revision.
    
*   `rego_version` - An optional field that specifies the rego-version of the Rego source files in the bundle. The value of this field is an `integer`; where `0` corresponds to v0 Rego ([OPA v0.x](/docs/v0-compatibility) syntax), `1` corresponds to v1 Rego (current OPA v1.x syntax), and `2` corresponds to v2 Rego (v1 syntax where [`and`, `or`](/docs/policy-reference/keywords/logical), and [`not`](/docs/policy-reference/keywords/not#improved-negation-semantics) are keywords without imports). Other values are rejected. If the field is not included in the manifest, OPA will enforce v1 syntax, or v0 if executed with the `--v0-compatible` flag. An existing bundle `rego_version` field takes precedence to the `--v0-compatible` flag.
    
*   `file_rego_versions` - An optional field that specifies per-file rego-version overrides to the `rego_version` field. The value of this field is a `map` where the keys are file paths relative to the bundle root directory (paths are absolute and start with `/`) and the values are `integer` rego-versions, as for `rego_version`. Glob patterns are accepted, to allow for a single entry to apply to multiple files. The behaviour is undefined for overlapping patterns. If a file is not matched by any pattern, the `rego_version` field is used. Existing bundle `rego_version` and `file_rego_versions` fields takes precedence to the `--v0-compatible` flag.
    
*   `roots` - If you expect to load additional data into OPA from outside the bundle (e.g., via OPA's HTTP API) you should include a top-level `roots` field containing of path prefixes that declare the scope of the bundle. See the section below on managing data from multiple sources. If the `roots` field is not included in the manifest it defaults to `[""]` which means that ALL data and policy must come from the bundle.
    
*   `wasm` - A list of OPA WebAssembly (Wasm) module files in the bundle along with metadata for how they should be evaluated. The following keys are supported:
    
    *   `entrypoint` - A string path defining what query path the wasm module is built to evaluate. Once loaded any usage of this path in a query will use the Wasm module to compute the value.
    *   `module` - A string path to the Wasm module relative to the root of the bundle.
*   `metadata` - An optional key that contains arbitrary metadata to accompany the bundle. This metadata is available for querying using `data.system`, along with the rest of the manifest.
    

For example, this manifest specifies a revision (which happens to be a Git commit hash) and a set of roots for the bundle contents. In this case, the manifest declares that it owns the roots `data.roles` and `data.http.example.authz`.

```
{  "revision": "7864d60dd78d748dbce54b569e939f5b0dc07486",  "roots": ["roles", "http/example/authz"]}
```

Another example, this time showing a Wasm module configured for `data.http.example.authz.allow`:

```
{  "revision": "7864d60dd78d748dbce54b569e939f5b0dc07486",  "roots": ["roles", "http/example/authz"],  "wasm": [    {      "entrypoint": "http/example/authz/allow",      "module": "path/to/policy.wasm"    }  ]}
```

For example, the manifest below specifies the global Rego version for the bundle using the `rego_version` field and uses the `file_rego_versions` field for overrides. This manifest describes a bundle that follows the OPA v1.0 syntax expect for policy files `/policy1.rego` and those under the folder `foo`.

```
{  "revision": "7864d60dd78d748dbce54b569e939f5b0dc07486",  "rego_version": 1,  "file_rego_versions": {    "/foo/*.rego": 0,    "/policy1.rego": 0  }}
```

### Manifest JSON Schema

A machine-readable JSON Schema (Draft 2020-12) describing the manifest format is published at [`https://openpolicyagent.org/schemas/bundle/v1/manifest.schema.json`](https://openpolicyagent.org/schemas/bundle/v1/manifest.schema.json). The schema is generated from the Go type definitions in [`v1/bundle/bundle.go`](https://github.com/open-policy-agent/opa/blob/main/v1/bundle/bundle.go) and stays in sync with them via a CI drift test, so it always reflects what the current `opa build` actually emits. Backward-incompatible changes will be published under a new path (e.g., `/v2/`).

Use it to validate manifests, generate typed bindings in non-Go languages, or feed it into JSON Schema-aware tooling. Example with [`ajv`](https://ajv.js.org/):

```
opa build -b bundle/tar -xzf bundle.tar.gz .manifestajv validate \  -s https://openpolicyagent.org/schemas/bundle/v1/manifest.schema.json \  -d .manifest
```

The top-level `Manifest` object does not set `additionalProperties: false`: the bundle loader has always ignored unknown top-level keys, and embedders that wrap OPA sometimes attach their own configuration alongside the documented fields. Sub-records like `WasmResolver` remain closed, since their shape is fully specified.

Some important details for bundle files:

*   OPA will only load data files named `data.json` or `data.yaml` (which contain JSON or YAML respectively). Other JSON and YAML files will be ignored.
*   The `*.rego` policy files must be valid [Modules](/docs/policy-language#modules).
*   OPA will only load Wasm modules named `policy.wasm`. Other WebAssembly binary files will be ignored.

info

YAML data loaded into OPA is converted to JSON. Since JSON is a subset of YAML, you are not allowed to use binary or null keys in objects and boolean and number keys are converted to strings. [YAML `!!binary` tags](https://ref.coddy.tech/yaml/yaml-binary-data) are not supported.

## Multiple Sources of Policy and Data

By default, when OPA is configured to download policy and data from a bundle service, the entire content of OPA's policy and data cache is defined by the bundle. However, if you need to load OPA with policy and data from multiple sources, you can implement your bundle service to generate bundles that are scoped to a subset of OPA's policy and data cache.

danger

Whenever possible, implement policy and data aggregation centrally. In some cases that's not possible (e.g., due to latency requirements.). When using multiple sources there are **no** ordering guarantees for which bundle loads first and takes over some root. If multiple bundles conflict, but are loaded at different times, OPA may go into an error state. It is highly recommended to use the health check and include bundle state: [Monitoring OPA](/docs/monitoring#health-checks)

To scope bundles to a subset of OPA's policy and data cache, include a top-level `roots` key in the bundle that defines the roots of the `data` namespace that are owned by the bundle.

For example, the following manifest would declare two roots (`acmecorp/policy` and `acmecorp/oncall`):

```
{    "roots": ["acmecorp/policy", "acmecorp/oncall"]}
```

If OPA was loaded with a bundle containing this manifest it would only erase and overwrite policy and data under these roots. Policy and data loaded under other roots is left intact.

When OPA loads scoped bundles, it validates that:

*   The roots are not overlapping (e.g., `a/b/c` and `a/b` are overlapped and will result in an error.) Note: This is _not_ enforced across multiple bundles. Only within the same bundle manifest.
    
*   The policies in the bundle are contained under the roots. This is determined by inspecting the `package` statement in each of the policy files. For example, given the manifest above, it would be an error to include a policy file containing `package acmecorp.other` because `acmecorp.other` is not contained in either of the roots.
    
*   The data in the bundle is contained under the roots.
    

If bundle validation fails, OPA will report the validation error via the Status API.

## Debugging Your Bundles

When you run OPA, you can provide bundle files over the command line. This allows you to manually check that your bundles include all of the files that you intended and that they are structured correctly. For example:

```
opa run bundle.tar.gz
```

## Signing

To ensure the integrity of policies (i.e. the policies are coming from a trusted source), policy bundles may be digitally signed so that industry-standard cryptographic primitives can verify their authenticity.

OPA supports digital signatures for policy bundles. Specifically, a signed bundle is a normal OPA bundle that includes a file named `.signatures.json` that dictates which files should be included in the bundle, what their SHA hashes are, and is cryptographically secure.

When OPA receives a new bundle, it checks that it has been properly signed using a (public) key that OPA has been configured with out-of-band. Only if that verification succeeds does OPA activate the new bundle; otherwise, OPA continues using its existing bundle and reports an activation failure via the status API and error logging.

warning

Bundle signature verification works differently depending on how bundles are loaded. Filesystem bundles (`--bundle` flag) use the `--verification-key` CLI flag pointing to a PEM file. Remote bundles define keys in the configuration file under the `keys` section. Sub-commands primarily used in pre-production (such as `opa eval`, `opa test`, etc.) do not verify bundle signatures at this point in time.

### Signature Format

Recall that a [policy bundle](#bundle-file-format) is a gzipped tarball that contains policies and data. A signed bundle differs from a normal bundle in that it has a `.signatures.json` file as well.

```
$ tar tzf bundle.tar.gz.manifest.signatures.jsonrolesroles/bindingsroles/bindings/data.json
```

The signatures file is a JSON file with an array of JSON Web Tokens (JWTs) that encapsulate the signatures for the bundle. Currently, you will be limited to one signature, as shown below. In the future, support for multiple signatures may be added to sign different files within the bundle.

```
{  "signatures": [    "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJmaWxlcyI6W3sibmFtZSI6Ii5tYW5pZmVzdCIsImhhc2giOiJjMjEzMTU0NGM3MTZhMjVhNWUzMWY1MDQzMDBmNTI0MGU4MjM1Y2FkYjlhNTdmMGJkMWI2ZjRiZDc0YjI2NjEyIiwiYWxnb3JpdGhtIjoiU0hBMjU2In0seyJuYW1lIjoicm9sZXMvYmluZGluZ3MvZGF0YS5qc29uIiwiaGFzaCI6IjQyY2ZlNjc2OGI1N2JiNWY3NTAzYzE2NWMyOGRkMDdhYzViODEzNTU0ZWJjODUwZjJjYzM1ODQzZTcxMzdiMWQifV0sImlhdCI6MTU5MjI0ODAyNywiaXNzIjoiSldUU2VydmljZSIsImtleWlkIjoibXlQdWJsaWNLZXkiLCJzY29wZSI6IndyaXRlIn0.ZjtUgXC6USwmhv4XP9gFH6MzZwpZrGpAL_2sTK1P-mg"  ]}
```

The JWT has the standard headers `alg` (for algorithm), `typ` (always JWT), and `kid` (for key id). It has a JSON payload of the following form:

```
{  "files": [    {      "name": ".manifest",      "hash": "c2131544c716a25a5e31f504300f5240e8235cadb9a57f0bd1b6f4bd74b26612",      "algorithm": "SHA-256"    },    {      "name": "roles/bindings/data.json",      "hash": "42cfe6768b57bb5f7503c165c28dd07ac5b813554ebc850f2cc35843e7137b1d",      "algorithm": "SHA-256"    }  ]}
```

| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `files[_].name` | `string` | Yes | Path of a file in the bundle. |
| `files[_].hash` | `string` | Yes | Output of the hashing algorithm applied to the file. |
| `files[_].algorithm` | `string` | Yes | Name of the hashing algorithm. |
| `scope` | `string` | No | Represents the fragment of signings. |
| `iat` | `string` | No | Time of signature creation since epoch in seconds. For informational purposes only. |
| `iss` | `string` | No | Identifies the issuer of the JWT. For informational purposes only. |

info

OPA will first look for the `keyid` on the command-line. If the `keyid` is empty, OPA will look for it in it's configuration. If `keyid` is still empty, OPA will finally look for `kid` in the JWT header.

To include additional claims in the JWT payload such as `scope`, `iat`, `iss` use the `--claims-file` flag in the `opa build` or `opa sign` commands to provide a JSON file containing optional claims. See `opa build --help` or `opa sign --help` for more details.

The following hashing algorithms are supported:

```
MD5SHA-1SHA-224SHA-256SHA-384SHA-512SHA-512-224SHA-512-25
```

To calculate the digest for unstructured files (i.e. all files except JSON or YAML files), apply the hash function to the byte stream of the file.

For structured files, read the byte stream and parse into a JSON structure; then recursively order the fields of all objects alphabetically and then apply the hash function to the result to compute the hash. This ensures that the digital signature is independent of whitespace and other non-semantic JSON features.

To generate a `.signatures.json` file for policy and data files that will be part of a bundle, see the `opa sign` command.

Signature Verification

When OPA receives a policy bundle that doesn't include the `.signatures.json` file and the bundle is not configured to use a signature, OPA does not perform signature verification and activates the bundle just as it always has.

A bundle is configured to verify signatures when it has a `bundles[_].signing` block (or `discovery.signing` for discovery bundles), or when it is loaded from the filesystem with `--verification-key`. Any `signing` block enables the feature, including an empty one. `keyid` selects which key to use and is not what enables enforcement.

If the top-level [`keys`](/docs/configuration#keys) value is set without a `signing` block set, signature verification is only applied to bundles containing signatures. This is weaker as a bundle without a signature is still activated regardless. You must add a `signing` block to enforce verification.

If a bundle contains a `.signatures.json` file but no verification key is available at all, verification fails, because OPA has nothing to verify the signature against.

| `.signatures.json` exists | verification configured by | verification performed | result |
| --- | --- | --- | --- |
| `no` | nothing | `no` | `NA` |
| `no` | top-level `keys` only | `no` | `activated` (warning logged at startup) |
| `no` | `signing` block or `--verification-key` | `yes` | `fail` — bundle missing .signatures.json file |
| `yes` | nothing | `yes` | `fail` — verification key not provided |
| `yes` | top-level `keys` only | `yes` | `depends on the verification steps described below` |
| `yes` | `signing` block or `--verification-key` | `yes` | `depends on the verification steps described below` |

When OPA receives a signed bundle it opens the `.signatures.json` file, grabs the JWT and performs the following steps:

*   Verify the JWT signature with the appropriate public key
    
*   Verify that the JWT payload and target directory specify the same set of files
    
*   Verify the content of each file by checking the hash recorded in the JWT payload is the same as the hash generated for that file
    

OPA activates the new bundle only if all the verification steps succeed; otherwise, it continues using its existing bundle and reports an activation failure via the status API and error logging.

The signature verification process uses each of the fields in the JWT header and payload as follows:

*   `files`: This list of files in the payload must match exactly the files in the bundle, and for each file the hash of the file must match
    
*   `kid`: If supplied in the header, dictates which key (and algorithm) to use for verification. The actual key is supplied via OPA out-of-band
    
*   `scope`: If supplied in the payload, must match exactly the value provided out-of-band to OPA
    
*   `iat`: unused for verification even if present in payload
    
*   `iss`: unused for verification even if present in payload
    

Signature Plugin

OPA supports the option to implement your own bundle signing and verification logic. This will be unnecessary for most and is intended for advanced use cases, such as leveraging key-related services from cloud providers. To implement your own signing and verification logic, you'll need to [extend OPA](/docs/extensions). Here is [an example](https://github.com/open-policy-agent/contrib/tree/main/custom_bundle_signing) to get you started.

When registering custom signing and verification plugins, you will need to register the Signer and the Verifier under the same plugin key, because the plugin key is stored in the signed bundle and informs OPA which Verifier is capable of verifying the bundle, e.g.

```
bundle.RegisterSigner("custom", &CustomSigner{})bundle.RegisterVerifier("custom", &CustomVerifier{})
```

## Delta Bundles

A regular _snapshot_ bundle represents the entirety of OPA’s policy and data cache. When a new _snapshot_ bundle is downloaded, OPA will erase and overwrite all the policy and data in its cache before activating the new bundle. The bundle can optionally be scoped to a subset of OPA’s policy and data cache by defining the `roots` in the bundle’s `.manifest` file.

Although OPA [caches](#caching) snapshot bundles to avoid unnecessary retransmission, servers must still retransmit the entire snapshot when any change occurs. If you need to propagate small changes to bundles without waiting for polling delays, consider using _delta_ bundles in conjunction with [HTTP Long Polling](#http-long-polling).

_Delta_ bundles provide a more efficient way to make data changes by containing patches to data instead of complete snapshots. _Delta_ bundles are structured differently from _snapshot_ bundles. A _delta_ bundle contains a single `patch.json` file at the root of the bundle which includes a [JSON Patch](https://datatracker.ietf.org/doc/html/rfc6902) (i.e., an array of one or more JSON objects). The operations in the JSON Patch will be applied to OPA's in-memory store in order.

info

_Delta_ bundles currently support updates to data only and not policies.

### Delta Bundle File Format

OPA expects a _delta_ bundle to contain an optional `.manifest` file and a required `patch.json` file that specifies a list of one or more patch operations on the data. OPA will generate an error if a _delta_ bundle contains any policy, data or wasm binary files. If the `.manifest` file specifies any `roots`, any data patch outside the bundle's roots will cause an error.

```
$ tar tzf bundle.tar.gz.manifestpatch.json
```

Below is an example of the `patch.json` file:

```
{  "data": [    { "op": "upsert", "path": "/a/b", "value": ["hello", "world"] },    { "op": "remove", "path": "/a/c" }  ]}
```

If OPA has previously activated a _snapshot_ bundle that did not contain a .manifest file, then the _delta_ bundle must not contain a `.manifest` file.

If OPA has a previously activated _snapshot_ bundle that did contain a `.manifest` file, then the _delta_ bundle may contain a `.manifest` file. Specifically if a previously activated _snapshot_ bundle contains a `.manifest` file that declares `roots` or `wasm` fields, a _delta_ bundle update MUST have the same values for the manifest `roots` and `wasm` fields from the original _snapshot_ bundle. This means a _delta_ bundle cannot be used to change the scope of the original bundle or update Wasm resolvers. A _delta_ bundle can however contain different values for the bundle's `revision` and `metadata`.

danger

An empty list of operations in a _delta_ bundle `patch.json` will remove all the data from OPA's in-memory store. I.e., the following are equivalent:

```
{  "data": []}
```

```
{  "data": [    { "op": "replace", "path": "/", "value": {} }  ]}
```

If there are no operations to apply to the data, the bundle server should return the same [`Etag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag) value as the last update. OPA will send the last `Etag` value in the [`If-None-Match`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-None-Match) Header.

Delta Bundle Patch Operations

Each patch operation defined in the `patch.json` file must have exactly one `op` member which indicates the operation to perform. Valid options include:

| op | Description |
| --- | --- |
| `"remove"` | The `"path"` specified will be removed from OPA's in-memory store. The `"value"` field is ignored for `"remove"` operations. The target path must exist for the operation to be successful. |
| `"replace"` | The value at the specified `"path"` will be replaced by the new value defined by the `"value"` field. The target path must exist for the operation to be successful. |
| `"upsert"` | The `"value"` will be set at the specified `"path"`. If the `"path"` specifies an array index, the `"value"` is inserted into the array at the specified index. If the `"path"` specifies an object member that does not already exist, a new member is added to the object. If the object member exists, its value is replaced. If the `"path"` does not exist, OPA will create and add it to its in-memory store. |

info

The `upsert` operation in not part of the [JSON Patch](https://datatracker.ietf.org/doc/html/rfc6902) standard.

The `"path"` field defines a JSON pointer path to the location to perform the operation on.

The `"value"` field defines the value to be added or replaced. Only required for `"upsert"` and `"replace"` operations.

Current Limitations

*   _Delta_ bundles only support updates to data. Policies cannot be updated using _delta_ bundles.
*   _Delta_ bundles do not support bundle signing. A bundle configured to verify signatures **rejects** _delta_ bundles with `delta bundles do not support signature verification`. Use `--skip-verify`, set `bundles[_].signing.allow_unsigned_delta_bundles`, or remove the `signing` block, to serve _delta_ bundles.
*   Unlike _snapshot_ bundles, activated _delta_ bundles are not persisted to disk when the `bundles[_].persist` field is `true`.

Delta Bundle FAQ

This section discusses some _delta_ bundle usage, edge cases and failure scenarios.

*   What happens if OPA cannot apply a data patch ?

Bundle activation will fail in this scenario. In the next attempt to download the bundle, OPA will set the value of the `If-None-Match` header of the bundle request to the last successful activation Etag value. This should help the Bundle Service to send the correct revision of the bundle to OPA.

*   What happens if OPA cannot reach the Bundle Service (for example. network failure) or is unable to download a bundle ?

OPA always includes the last successful activation Etag value in the bundle request. When OPA eventually reconnects with the server, the value of the `If-None-Match` header of bundle request could be empty indicating that OPA was not able to activate the first revision of the bundle itself. This helps the server to re-transmit the correct bundle revision.

In case OPA has already activated a revision of the bundle, and reaches out to the server with the last successful activation Etag value, the server now knows to send the next bundle revision. This could either be a snapshot or delta bundle. One possible approach on the server-side, would be to first send a snapshot bundle and then send delta bundles to perform data patch operations. The server could maintain the order in which the bundles should go out for example, assigning an Etag value to each bundle revision. Hence, it can figure out the right bundle to send by looking up the `If-None-Match` header of bundle request and then lining-up the next bundle in the queue.

*   Does a _delta_ bundle always need to be preceded by a _snapshot_ bundle ?

No. OPA will activate a _delta_ bundle if all the patch operations in it were successfully applied. Note that a _snapshot_ bundle would erase and overwrite policy and data under the manifest `roots`.

## Implementations

The Bundle API is simple. Most HTTP servers capable of serving static files will do. While not strictly required in all deployments, it is also good if the implementation supports:

*   HTTP caching using the [ETag header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag). This keeps OPA from having to download a bundle unless the bundle's content have changes.
*   Authentication. When exposing a bundle at a remote endpoint, it is often desirable to protect the data by requiring all requests to the endpoint to be authenticated.

This document lists some of the more common HTTP servers suitable as bundle servers, along with instructions for how to set them up as such.

### Amazon S3

OPA Bundle Support

| Feature | Supported |
| --- | --- |
| Caching headers | Yes |
| Authentication methods | [AWS Signature](https://www.openpolicyagent.org/docs/latest/configuration/#aws-signature) |

Setup Instructions

1.  Search for "S3" and on the "Buckets" page, click "Create bucket".
2.  Fill in the form according to your preferences (name, region, etc).
3.  Either choose "Block all public access" for internal systems, or unmark the checkbox for that to allow external (authenticated) requests.
4.  You can now upload your bundle to the bucket. If you try to download it right away you'll notice that by default you're unauthorized to do so.
5.  To allow anyone to read the bundle, click on it and select "Make public" from the "Object actions" dropdown menu. If not, proceed to configure authentication.

Authentication

Authentication can be configured to either use the credentials of a service account stored in the environment, or to use credentials fetched from the AWS metadata API. The latter is only available from services running inside of AWS (on EC2 or ECS).

Both methods are going to need a policy for either the service account or the IAM role, so when that is mentioned in the steps for either method you may refer to the example below.

**Example IAM policy**

```
{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": [        "s3:ListBucket"      ],      "Resource": [        "arn:aws:s3:::my-example-opa-bucket"      ]    },    {      "Effect": "Allow",      "Action": [        "s3:PutObject",        "s3:GetObject"      ],      "Resource": [        "arn:aws:s3:::my-example-opa-bucket/*"      ]    }  ]}
```

**NOTE:** The above policy permits both uploads and downloads, which is good for testing. The OPA client however needs only the `s3:GetObject` permission for downloads and should be the only permission granted for production use cases.

Environment Credentials

1.  Go to the "IAM" section of the AWS console. Choose "Users" and "Create new user". Select a name for the user, and the "Programmatic access" option.
2.  On the following "Permissions" page, choose "Attach existing policies directly" and then press "Create policy". Select the JSON tab and paste a policy like the example shown above, replacing `my-example-opa-bucket` with the name of your bucket.
3.  Once the policy has been created, it can be assigned to the user. With the user having been created, make sure to note down the AWS access key ID and the AWS secret access key, as they will be the credentials used for authentication.

Metadata Credentials

1.  Go to the "IAM" section of the AWS console. Choose "Roles" and "Create role". For type, select "AWS service" and for use case, choose EC2, or wherever you'll be running OPA.
2.  On the following "Permissions" page, choose "Create policy". Select the JSON tab and paste a policy like the example shown above, replacing `my-example-opa-bucket` with the name of your bucket.
3.  Once the policy has been created, it can be assigned to the role.
4.  With the role created, go to the EC2 instance view. Select an instance where OPA will run and select "Actions" -> "Security" -> "Modify IAM role". Select the role created in previous steps.

Web Identity Credentials

Using EKS IAM Roles for Service Account (Web Identity) Credential.

Below are steps to use OpenID connect provider and Kubernetes.

1.  Go to the "IAM" section of the AWS console.
    
2.  Click Add provider and select OpenID connect.
    
3.  For Provider URL enter the one belonging to your chosen Kubernetes cluster.
    
4.  Click on Get thumbprint
    
5.  For the audience enter: sts.amazonaws.com
    
6.  Add the provider.
    
7.  Once the provider is added, copy the ARN for the identity provider. Here's an example ARN: `arn:aws:iam::<your AWS account ID>:oidc-provider/oidc.eks.ap-northeast-1.amazonaws.com/id/DFGHJKKJHGF34HFDFGHY44TRFDE4RGDF`
    
8.  Create an IAM role (e.g., `app_dev_role`) with the policy created above and assign it to the Kubernetes service account.
    
9.  Go to Trust relationships inside the created role and click Edit trust relationship and enter the following policy document.
    
    ```
    {  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Federated": "<the ARN of the Identity provider from step 7, e.g. arn:aws:iam::123456789012:oidc-provider/oidc.eks.ap-northeast-1.amazonaws.com/id/DFGHJKKJHGF34HFDFGHY44TRFDE4RGDF where 123456789012 is the account ID of your AWS account, and DFGHJK...4RGDF is the OpenID Connect URL's end>"      },      "Action": "sts:AssumeRoleWithWebIdentity",      "Condition": {        "StringEquals": {          "<the OpenID connect URL, e.g. oidc.eks.ap-northeast-1.amazonaws.com/id/B7060B6E991747ADDDC61ADD4B7875CF>:sub": "system:serviceaccount:<Kubernetes namespace, e.g. app-dev>:<the Kubernetes serviceaccount name, eg: app-dev-service-account>"        }      }    }  ]}
    ```
    
10.  Create the Kubernetes service account.
     
     ```
     apiVersion: v1kind: ServiceAccountmetadata:  annotations:    eks.amazonaws.com/role-arn: <the ARN of the IAM role from your account, e.g. arn:aws:iam::<aws_account eg, 123456789012>:role/app_dev_role>  name: <service account name, e.g. app-dev-service-account>  namespace: <k8 namespace, e.g. app-dev>automountServiceAccountToken: false
     ```
     
11.  Configure your Kubernetes resources to use this service account.
     
     ```
     apiVersion: apps/v1kind: Deploymentmetadata:  ******spec:  ******  template:    *******    spec:      serviceAccountName: app-dev-service-account # <--- like this      automountServiceAccountToken: true      containers:      ******
     ```
     

You should now be able to access AWS services from your Kubernetes cluster.

The above steps should add the following variable to the pod.

```
AWS_ROLE_ARN=<the ARN of the IAM role from your account, e.g. arn:aws:iam::123456789012:role/app_dev_role>AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
```

Please read [IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) for more details.

Testing Authentication

Use the [AWS CLI tools](https://aws.amazon.com/cli/) (see ["Upload Bundle"](#upload-bundle) below).

Upload Bundle

Bundle uploads to S3 are easily facilitated using the `aws` command in the [AWS CLI tools](https://aws.amazon.com/cli/).

```
aws --profile=opa-service-account s3 cp bundle.tar.gz s3://my-example-opa-bucket/
```

Example OPA Configuration

Environment Credentials

With the environment variables `AWS_REGION`, `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` set, the following configuration will extract the credentials from the [environment](https://www.openpolicyagent.org/docs/latest/configuration/#using-static-environment-credentials).

```
services:  s3:    url: https://my-example-opa-bucket.s3.eu-north-1.amazonaws.com    credentials:      s3_signing:        environment_credentials: {}bundles:  authz:    service: s3    resource: bundle.tar.gz
```

**NOTE:** the S3 `url` is the bucket's regional endpoint.

Metadata Credentials

In order for this to work it is required that the permissions you created in the "Authentication" steps above are embedded in an IAM Role, which is then assigned to the EC2 instance hosting OPA.

```
services:  s3:    url: https://my-example-opa-bucket.s3.eu-north-1.amazonaws.com    credentials:      s3_signing:        metadata_credentials:          aws_region: eu-north-1          iam_role: my-opa-bucket-access-rolebundles:  authz:    service: s3    resource: bundle.tar.gz
```

**NOTE:** the S3 `url` is the bucket's regional endpoint.

Assume Role Credentials

```
services:  s3:    url: https://my-example-opa-bucket.s3.us-east-1.amazonaws.com    credentials:      s3_signing:        assume_role_credentials:          aws_region: us-east-1          iam_role_arn: arn:aws::iam::123456789012:role/demo          session_name: my-open-policy-agent # Optional. Default: open-policy-agent          aws_signing: # similar to s3_signing            metadata_credentials:              aws_region: us-east-1              iam_role: s3accessbundles:  authz:    service: s3    resource: bundle.tar.gz
```

**NOTE:** the S3 `url` is the bucket's regional endpoint.

Web Identity Credentials

```
services:  s3:    url: https://my-example-opa-bucket.s3.eu-north-1.amazonaws.com    credentials:      s3_signing:        web_identity_credentials:          aws_region: eu-north-1          session_name: my-open-policy-agent # Optional. Default: open-policy-agentbundles:  authz:    service: s3    resource: bundle.tar.gz
```

**NOTE:** the S3 `url` is the bucket's regional endpoint.

Credential Provider Chaining

Multiple AWS credential providers can be configured. OPA will follow an _internally defined_ order to try each of the credential provider given in the configuration till success. Following order of precedence is followed when multiple credential provider is given in the configuration

1.  Environment Credential
2.  Assume Role Credential
3.  Web Identity Credential
4.  Profile Credential
5.  Metadata Credential

```
services:  s3:    url: https://my-example-opa-bucket.s3.eu-north-1.amazonaws.com    credentials:      s3_signing:        metadata_credentials:          aws_region: eu-north-1          iam_role: my-opa-bucket-access-role        environment_credentials: {}bundles:  authz:    service: s3    resource: bundle.tar.gz
```

**NOTE:** In this example, OPA will look for AWS credentials in the environment first before trying metadata endpoint. S3 signing will fail if none of the providers are successful.

### Google Cloud Storage

OPA Bundle Support

| Feature | Supported |
| --- | --- |
| Caching headers | Yes |
| Authentication methods | [GCP Metadata Token](https://www.openpolicyagent.org/docs/latest/configuration/#gcp-metadata-token)   [OAuth2 JWT Bearer Grant Type](https://www.openpolicyagent.org/docs/latest/configuration/#oauth2-jwt-bearer-grant-type) |

Setup Instructions

1.  In the left pane menu, choose "Cloud Storage". Click "New bucket".
2.  Fill in the form according to your preferences (name, region, availability, etc).
3.  Once the bucket is created, you can press "Upload" to upload a test bundle. Clicking this will provide a link to the bundle which you can use in your OPA configuration.
4.  At this stage you can either choose to make the bucket public (by clicking "Permissions") or to configure a service account for authenticated access.

Authentication

GCP Metadata Token Authentication

If your instance of OPA runs inside GCP, you'll be able to authenticate using GCP metadata tokens. These tokens by default carry all the permissions granted to the default service account, so you might still want to create a dedicated service account for this purpose (see [JWT Bearer Grant Type](#jwt-bearer-grant-type) below).

JWT Bearer Grant Type

Use this for [authenticating](https://docs.cloud.google.com/storage/docs/authentication) _external_ clients, i.e. OPA instances running outside the GCP environment.

1.  Search for "credentials" in the top search box and choose "Credentials - APIs and Services".
2.  Click "Create Credentials" followed by "Service Account."
3.  Fill in a name for the account and proceed to select roles.
4.  Choose "Storage Object Viewer" for read access and "Storage Object Creator" for write access (if scripted uploads is desired).
5.  Click the newly created service account and then the "Keys" tab. Press "Add Key" and either "Create new" or upload an existing one.
6.  If creating new, choose to download the private key in JSON format (not P12).
7.  Open the JSON file just downloaded and copy the PEM encoded value of the `private_key` attribute. This is the key you'll use for your OPA configuration.

Testing Authentication

To test GCP metadata token or JWT bearer grant type authentication, set up OPA with the relevant config and run the server.

Upload Bundle

Uploading a bundle is trivial with the `gsutil` command included with the [Google Cloud SDK](https://docs.cloud.google.com/sdk/docs/install-sdk).

```
gsutil cp bundle.tar.gz gs://<bucket-name>/
```

Example OPA Configuration

GCP Metadata Token Authentication

```
services:  gcs:    url: https://storage.googleapis.com/storage/v1/b/${BUCKET_NAME}/o    credentials:      gcp_metadata:        scopes:        - https://www.googleapis.com/auth/devstorage.read_onlybundles:  authz:    service: gcs    # NOTE ?alt=media is required    resource: "bundle.tar.gz?alt=media"
```

If the resource (the object in the gcs bucket) contains slashes (/) or other special characters, these need to be url-encoded here, e.g. `bundles/bundle.tar.gz?alt=media` should be entered as `bundles%2fbundle.tar.gz?alt=media`. Please refer to the [official documentation](https://cloud.google.com/storage/docs/request-endpoints#encoding) for more information.

Google Cloud Storage Bundle and JWT Bearer Authentication

```
services:  gcp:    url: https://storage.googleapis.com/storage/v1/b/${BUCKET_NAME}/o    credentials:      oauth2:        grant_type: jwt_bearer        token_url: https://oauth2.googleapis.com/token        signing_key: jwt_signing_key # references the key in `keys` below        scopes:        - https://www.googleapis.com/auth/devstorage.read_only        additional_claims:          aud: https://oauth2.googleapis.com/token          iss: opa-client@my-account.iam.gserviceaccount.combundles:  authz:    service: gcp    # NOTE ?alt=media is required    resource: "bundle.tar.gz?alt=media"keys:  jwt_signing_key:    algorithm: RS256    private_key: ${BUNDLE_SERVICE_SIGNING_KEY}
```

### Azure Blob Storage

OPA Bundle Support

| Feature | Supported |
| --- | --- |
| Caching headers | Yes |
| Authentication methods | [OAuth2 Client Credentials](https://www.openpolicyagent.org/docs/latest/configuration/#oauth2-client-credentials),   [OAuth2 Client Credentials JWT authentication](https://www.openpolicyagent.org/docs/latest/configuration/#oauth2-client-credentials-jwt-authentication) |

Note that for the time being, the [Shared Key or Shared Access Signature (SAS)](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-requests-to-azure-storage) options are [not supported](https://github.com/open-policy-agent/opa/issues/2964).

Setup Instructions

1.  Any type of storage in Azure is grouped in Storage Accounts. If you have one already, skip to step 3.
2.  From the Azure console, select "Storage Accounts" followed by "New". Fill in the form (name, region, etc) according to your preferences. One thing to note when selecting "account kind", make sure to pick the Storage V2 (general purpose v2) option and not the legacy BlobStorage kind.
3.  With the storage account deployed, press "Go to resource" to create a new storage resource.
4.  Select "Containers" and press the plus sign to create a new storage container.
5.  Name your container and select access level. Choose "Private" to require authentication, or "Blob" to allow unauthenticated read access.
6.  Press "upload" and select the bundle from your local filesystem.
7.  Clicking the filename should bring up a properties window where the public URL to the bundle is included.

Authentication

1.  Go to Azure Active Directory.
2.  In the left menu, click "App Registrations" followed by "New Registration". Name your app (client) amd leave the other options be. Click "Register".
3.  Click "Certificates and Secrets". Either create a secret to be used for [OAuth2 Client Credentials](https://www.openpolicyagent.org/docs/latest/configuration/#oauth2-client-credentials) or upload a certificate for [OAuth2 Client Credentials JWT authentication](https://www.openpolicyagent.org/docs/latest/configuration/#oauth2-client-credentials-jwt-authentication).
4.  In the menu to the left, click "API permissions". Click "Add a permission". Choose "Azure Storage" and check the `user_impersonation` checkbox.
5.  Click "Add admin consent for Default Directory". Answer Yes on the followup question.
6.  Navigate back to your storage account. Click "Access Control (IAM)". Click "Add role assignments".
7.  Select the "Storage Blob Data Contributor" role. Leave "Assign access to" as "User, group or service principal". Search and select the name of the app created in step 2.
8.  Configuration is now complete. Go back to "App Registrations" in the Active Directory view to check details like tenant ID, application ID and endpoints. You'll need those when configuring OPA (see [Example Configuration](#example-opa-configuration) below).

Testing Authentication

Use Curl to test client authentication with a secret.

```
curl --silent \     --data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=https://storage.azure.com/.default" \     "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token"
```

Upload Bundle

Uploading bundles to Azure Blob storage is easily done using the [azcopy](https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10) tool. Make sure to first properly [authorize](https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-authorize-user-identity) the user to be able to upload to Blob storage.

By now you should be able to login interactively using `azcopy login --tenant-id <Active Directory tenant ID>`. Since you'll most likely will want to log in from scripts (to upload bundles programmatically), you should however create an Azure AD application, and a [service principal](https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal) to do so. Good news! If you've followed the Authentication steps above, you already have one.

**Uploading bundle using client secret authentication**

```
AZCOPY_SPA_CLIENT_SECRET='<application_client_secret>' azcopy login \  --service-principal \  --tenant-id <tenant-id> \  --application-id <application-id>azcopy copy bundle.tar.gz https://<storage-account-id>.blob.core.windows.net/<container-id>/bundle.tar.gz
```

**Uploading bundle using client certificate authentication**

```
AZCOPY_SPA_CERT_PASSWORD='<client_cert_password>' azcopy login \  --service-principal \  --tenant-id <tenant-id> \  --certificate-path <path-to-certificate-file> --tenant-id <tenant-id>azcopy copy bundle.tar.gz https://<storage-account-id>.blob.core.windows.net/<container-id>/bundle.tar.gz
```

**Uploading bundle using Curl**

```
token=$(curl --silent \             --data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=https://storage.azure.com/.default" \             "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token" | jq -r .access_token)curl --silent \     -X PUT \     --data-binary "@bundle.tar.gz" -H "X-Ms-Version: 2020-04-08" -H "Authorization: Bearer $token" \     https://styra.blob.core.windows.net/opa/bundle.tar.gz
```

Example OPA Configuration

Azure Blob Storage Bundle and Client Credentials Authentication

```
services:  blob:    url: https://my-storage-account.blob.core.windows.net    headers:      # This header _must_ be present in all authenticated requests      x-ms-version: "2020-04-08"    credentials:      oauth2:        token_url: "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token"        client_id: "${CLIENT_ID}"        client_secret: "${CLIENT_SECRET}"        scopes:        - https://storage.azure.com/.defaultbundles:  authz:    service: blob    resource: my-container/bundle.tar.gz
```

Note that the `$CLIENT_ID` is what is referred to as the "Application ID" inside your Azure account.

Azure Blob Storage Bundle and Client Credentials JWT Authentication

```
keys:  blob_key:    algorithm: RS256    private_key: "${PRIVATE_KEY_PEM}"services:  blob:    url: https://my-storage-account.blob.core.windows.net    headers:      # This header _must_ be present in all authenticated requests      x-ms-version: "2020-04-08"    credentials:      oauth2:        token_url: "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token"        signing_key: blob_key        thumbprint: "8F1BDDDE9982299E62749C20EDDBAAC57F619D04"        include_jti_claim: true        scopes:        - https://storage.azure.com/.default        additional_claims:          aud: "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token"          iss: "${CLIENT_ID}"          sub: "${CLIENT_ID}"bundles:  authz:    service: blob    resource: opa/bundle.tar.gz
```

Note that the `$CLIENT_ID` is what is referred to as the "Application ID" inside your Azure account. Also note in particular how the `thumbprint` property is required for Azure. The value expected here can be found under "Certificates and Secrets" in your application's configuration.

![Certificate thumbprint](/assets/images/thumbprint-b621d36dcbb5f271056dc85dae89577f.png)

### Nginx

Nginx offers a simple but competent bundle server for those who prefer to host their own and is also suitable for local testing.

| Feature | Supported |
| --- | --- |
| Caching headers | Yes |
| Authentication methods | [Bearer Token](https://www.openpolicyagent.org/docs/latest/configuration/#bearer-token) 1   [OAuth2 Client Credentials JWT authentication](https://www.openpolicyagent.org/docs/latest/configuration/#oauth2-client-credentials-jwt-authentication) 2 |

1Nginx does not support bearer token authentication, but it does support [basic auth](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/). This can be achieved by setting `services[_].credentials.bearer.scheme` to `Basic` in the OPA configuration, and providing the base64 encoded credentials as the token.  
2Only available with Nginx Plus.

Upload Bundle

Either use the [nginx-upload-module](https://docs.nginx.com/) or upload bundles out-of-band with SSH or similar.

Example OPA Configuration

```
services:  nginx:    url: https://my-nginx.example.com    credentials:      bearer:        token: dGVzdGluZzp0ZXN0aW5n        scheme: Basicbundles:  authz:    service: nginx    resource: /bundle.tar.gz
```

### OCI Registry

OPA is able to interact with [OCI](https://opencontainers.org/) compatible registries to be able to download and use policies stored as containers. To configure OPA to use an OCI repository see the [service configuration section](/docs/configuration#services)

**Structure** The bundle container is composed of 3 layers:

*   the manifest layer - contains the information about the tarball layer of the container(the digest, size, mediatype and annotations) and the config layer
*   the bundle tarball layer - the actual bundle tarball
*   the configuration layer - currently empty

For OCI compatible registries an _**oci**_ folder is created in the [persistence directory](/docs/configuration#miscellaneous). If this value is not set, because the OCI downloader plugin requires a storage path, the system's temporary folder location will be used instead. This folder should be maintained by the user. Back up or clean up this folder periodically as this acts as a local cache for the OCI downloader.

**Current Limitations** The OCI Downloader plugin used by OPA has a couple of limitation:

*   it accepts only **one** layer per image that contains the bundle tarball
*   it can download only the following application media types:
    *   `application/vnd.oci.image.layer.v1.tar+gzip`
    *   `application/vnd.oci.image.manifest.v1+json`
    *   `application/vnd.oci.image.config.v1+json`
    *   `application/vnd.oci.image.index.v1+json`
    *   `application/vnd.docker.distribution.manifest.list.v2+json`

**Image indexes** A tag may also resolve to an image index (`application/vnd.oci.image.index.v1+json`) or a Docker manifest list (`application/vnd.docker.distribution.manifest.list.v2+json`) rather than directly to an image manifest. Build tooling produces one routinely — `docker buildx` wraps even a single-platform push in an index. OPA descends into the index and uses the first referenced manifest that has an `application/vnd.oci.image.layer.v1.tar+gzip` layer, skipping the `unknown`/`unknown` platform entries that build tools attach for provenance and SBOM attestations.

Note that the bundle layer itself must always use the OCI media type above. Traversing a Docker manifest list only gets OPA as far as the manifests it references; a bundle stored under the Docker layer type (`application/vnd.docker.image.rootfs.diff.tar.gzip`) is still not recognized.

Because the bundle is identified by that layer media type alone, and because OCI container images use the same media type for their filesystem layers, OPA cannot tell a bundle tarball apart from a container filesystem layer. Publish bundles as their own image, as described below, rather than adding one to an image that also ships a filesystem.

Building and Publishing Policy Containers

There are multiple ways to build an image from a policy code base using different tools.

Using OPA and ORAS CLIs

To build and push a policy bundle to a remote OCI registry with the [OPA CLI](/docs/cli) and [ORAS CLI](https://oras.land/docs/installation/) you can use the following commands:

*   `opa build <path_to_src>` will allow you to build a bundle tarball from your OPA policy and data files

Provide a config manifest to the ORAS CLI and the tarball itself:

*   `oras push <registry>/<org>/<repo>:<tag> --manifest-config <you_config_json>:application/vnd.oci.image.config.v1+json <the_tarball_obtained_from_opa_build>:application/vnd.oci.image.layer.v1.tar+gzip`

Using an empty(`{}`) `manifest-config` json file should be sufficient to be able to push and allow the OCI downloader to use the remote policy image.

Maintaining a policy-as-code repository

One of the easiest method of managing your policy bundles is to store your code base in a hosted repository service like GitHub or GitLab and set up an automated way to build and publish your code as a container to the desired registry using a CI(ex. GitHub Action).

Example

In this example, the [ghcr.io](https://ghcr.io) OCI registry is used as the upstream repository and the OPA and ORAS CLI as the build and publishing tool.

Starting from scratch

Set up a basic policy example structured as:

```
└── src    ├── data.json    ├── .manifest    └── policies        └── hello.rego
```

The _hello.rego_ file contains a very simple example:

```
package policies.playdefault hello = falsehello {    m := input.message    m == "world"}
```

The _.manifest_ file specifies the root only as:

```
{  "roots": ["policies"],  "metadata": {    "required_builtins": {      "builtin1": []    }  }}
```

And the _data.json_ file is empty json:

```
{}
```

Building your policy

To build the bundle tarball, use the OPA CLI and run the following command:

```
opa build .src/
```

Pushing the container to a remote registry

Prepare an empty config.json file that contains:

```
{}
```

To push the build image to an upstream registry, first log in using:

```
oras login ghcr.io
```

Push the policy using:

```
oras push ghcr.io/someorg/policy-hello:1.0.0 --config config.json:application/vnd.oci.image.config.v1+json bundle.tar.gz:application/vnd.oci.image.layer.v1.tar+gzip
```

Spin up the policy with OPA CLI

With the image pushed, prepare the OPA configuration.

In this example the configuration.yaml looks like this. The pushed image is private, so credentials are needed for OPA to download it:

```
services:  ghcr-registry:    url: https://ghcr.io    type: oci    credentials:      bearer:        scheme: "Bearer"        token: "<mytoken>"bundles:  authz:    service: ghcr-registry    resource: ghcr.io/someorg/policy-hello:1.0.0    persist: true    polling:      min_delay_seconds: 30      max_delay_seconds: 120
```

In the above configuration, the 1.0.0 tag of the image is pinned. OPA will identify this image by the tag and the descriptor SHA. If the SHA of the image is changed upstream, OPA will redownload and activate the changes.

Running the _opa CLI_ with this configuration opens an interactive terminal (REPL) showing the loaded bundle:

```
opa run -c configuration.yaml
```

The terminal should show that the bundle has been loaded and activated:

```
> {"level":"info","msg":"Bundle loaded and activated successfully.","name":"authz","plugin":"bundle","time":"2022-06-15T16:50:53+03:00"}> data{  "policies": {    "play": {      "hello": false    }  }}> exit
```

Start OPA as a server using:

```
opa run --server --set default_decision=policies -c configuration.yaml
```

To interact with the server you can do a simple **curl** to verify if it works as intended:

```
curl localhost:8181 -i -d '{ "message":"world"}' -H 'Content-Type:application/json'HTTP/1.1 200 OKContent-Type: application/jsonDate: Wed, 15 Jun 2022 13:55:19 GMTContent-Length: 23{"play":{"hello":true}}
```

```
curl localhost:8181 -i -d '{ "message":"other"}' -H 'Content-Type:application/json'HTTP/1.1 200 OKContent-Type: application/jsonDate: Wed, 15 Jun 2022 13:56:13 GMTContent-Length: 24{"play":{"hello":false}}
```

## Ecosystem Projects

The Bundle API supports managing policies and data. The following projects all make use of this API if you're looking for inspiration or examples of how to use it.

![](/assets/images/conftest-92a1aebfb4ea664b7d9c550b29f450a5.png)

### Conftest

Conftest supports the loading of policy in a bundle format. The feature is [documented here](https://www.conftest.dev/sharing/).

[View Details](/ecosystem/entry/conftest)

![](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjIwMCIgdmlld0JveD0iMCAwIDIwMCAyMDAiPgogIDxkZWZzPgogICAgPGxpbmVhckdyYWRpZW50IGlkPSJsaW5lYXItZ3JhZGllbnQiIHgxPSIwLjUiIHgyPSIwLjUiIHkyPSIxIiBncmFkaWVudFVuaXRzPSJvYmplY3RCb3VuZGluZ0JveCI+CiAgICAgIDxzdG9wIG9mZnNldD0iMCIgc3RvcC1jb2xvcj0iIzcwZDBkMyIvPgogICAgICA8c3RvcCBvZmZzZXQ9IjEiIHN0b3AtY29sb3I9IiMwNTdiODAiLz4KICAgIDwvbGluZWFyR3JhZGllbnQ+CiAgICA8Y2xpcFBhdGggaWQ9ImNsaXAtTG90dGllLTIwMCI+CiAgICAgIDxyZWN0IHdpZHRoPSIyMDAiIGhlaWdodD0iMjAwIi8+CiAgICA8L2NsaXBQYXRoPgogIDwvZGVmcz4KICA8ZyBpZD0iTG90dGllLTIwMCIgY2xpcC1wYXRoPSJ1cmwoI2NsaXAtTG90dGllLTIwMCkiPgogICAgPHJlY3Qgd2lkdGg9IjIwMCIgaGVpZ2h0PSIyMDAiIGZpbGw9InJnYmEoMTgsMTgsMTgsMCkiLz4KICAgIDxnIGlkPSJMb3R0aWUtMjAweDIwMCIgdHJhbnNmb3JtPSJ0cmFuc2xhdGUoMCAwLjA4NikiPgogICAgICA8cGF0aCBpZD0iUGF0aF84IiBkYXRhLW5hbWU9IlBhdGggOCIgZD0iTTEzNi4yMTEsMTEwLjQ4OWMtNC44MzQsNS4xOS0xNC4yNjUsNC42ODctMjAuNDcxLS42ODFzLTcuNDYxLTEzLjA2Ny0zLjI4NS0xNy41NjFjMi4xOTItMi4yLDE0LjI0Ny0xMy4xNiwyMy40NzQtMjUuNzE5LDkuNzQzLTEyLjE1OCwxNi42NTgtMjUuOTEsMjAuNTE4LTI0LjQxNiwzLjc2NSwxLjI3MywzLjc3NiwxOC43MDctMS45MjksMzQuNzY5QzE0OS40NzUsOTMuMiwxMzguNzE1LDEwOC4xNTUsMTM2LjIxMSwxMTAuNDg5WiIgZmlsbD0iIzFmNTM1NSIvPgogICAgICA8cGF0aCBpZD0iUGF0aF85IiBkYXRhLW5hbWU9IlBhdGggOSIgZD0iTTEyNC44NCw4Ny41NzFjNC44MzgtMS42LDMwLjA2NS0xMy40MTMsMzAuNjkxLTEzLjc1MnEtLjQ3MywxLjUzNC0xLjAxNCwzLjA2MWMtNS4wNDQsMTYuMzIzLTE1LjgsMzEuMjc1LTE4LjMwOCwzMy42MDgtNC44MzQsNS4xOS0xNC4yNjUsNC42ODctMjAuNDcxLS42ODFhMTcuMDg1LDE3LjA4NSwwLDAsMS00Ljg4NC02Ljc2NEMxMTEuMDkxLDEwMS44ODQsMTExLjUsOTEuOTc1LDEyNC44NCw4Ny41NzFaIiBmaWxsPSIjMjM2OTZjIi8+CiAgICAgIDxwYXRoIGlkPSJQYXRoXzEwIiBkYXRhLW5hbWU9IlBhdGggMTAiIGQ9Ik0xNDAuNzM1LDEyNC4xNzJjLTYuNTI1LDIuNzc5LTE0LjkzOS0xLjUxLTE4LjQzLTguOTM2cy0xLjUxLTE0Ljk3MSw0LjEzLTE3LjM4MmMyLjktMS4xMTYsMTguMzY0LTYuMjM5LDMxLjktMTMuOTY5QzE3Mi4xNzMsNzYuNzMzLDE4NC4wNzgsNjYuOTc0LDE4Nyw2OS45MDdjMi45MjQsMi42OTMtNC4xNDYsMTguNjI4LTE1Ljg4MywzMC45OUMxNTkuODc2LDExMy43NjMsMTQzLjk3MiwxMjMuMDU3LDE0MC43MzUsMTI0LjE3MloiIGZpbGw9IiMyNzdmODIiLz4KICAgICAgPHBhdGggaWQ9IlBhdGhfMTEiIGRhdGEtbmFtZT0iUGF0aCAxMSIgZD0iTTE2OS4xMzgsODcuNjU4Yy0uNzI3LDIuMDU5LTEuNTQ3LDQuMTI2LTIuNDY1LDYuMTYxLTYuMzcsMTUuODUyLTE4LjMyNCwyOS44NjgtMjEuMDEzLDMxLjk4Ny01LjI0NCw0Ljc3NS0xNC42LDMuNS0yMC4zNDUtMi4zNjNzLTYuMzU5LTEzLjYzOC0xLjgyOC0xNy43NzNDMTIzLjkzNywxMDUuMjg4LDE2Ni43NCw4OC44MiwxNjkuMTM4LDg3LjY1OFoiIGZpbGw9IiMyZjk4OWMiLz4KICAgICAgPHBhdGggaWQ9IlBhdGhfMTIiIGRhdGEtbmFtZT0iUGF0aCAxMiIgZD0iTTEzNS41NjQsMTM2LjQ5MWMtNy4wOTEtLjEwOS0xMy4wMzktNy40NDQtMTMuMjE2LTE1LjY0Ny0uMTgtOC4yMjEsNC43LTE0LjI5NSwxMC44MjktMTQuMjEsMy4xLjE1NSwxOS4zMTYsMS43NTIsMzQuODIuMTgsMTUuNTUzLS45MTksMzAuMzk0LTUuMDA2LDMxLjg3Mi0xLjE0LDEuNTc5LDMuNjQ3LTExLjM1LDE1LjM0Mi0yNy4wOTMsMjEuODc1QzE1Ny4yODQsMTM0Ljc0NywxMzguOTc1LDEzNi43ODUsMTM1LjU2NCwxMzYuNDkxWiIgZmlsbD0iIzM2YjFiNSIvPgogICAgICA8cGF0aCBpZD0iUGF0aF8xMyIgZGF0YS1uYW1lPSJQYXRoIDEzIiBkPSJNNjMuNzkxLDExMC40ODljNC44MzQsNS4xOSwxNC4yNjUsNC42ODcsMjAuNDcxLS42ODFzNy40NjEtMTMuMDY3LDMuMjg1LTE3LjU2MWMtMi4xOTItMi4yLTE0LjI0Ny0xMy4xNi0yMy40NzQtMjUuNzE5QzU0LjMzLDU0LjM3LDQ3LjQxNSw0MC42MTgsNDMuNTU1LDQyLjExMmMtMy43NjUsMS4yNzMtMy43NzcsMTguNzA3LDEuOTI4LDM0Ljc2OUM1MC41MjcsOTMuMiw2MS4yODcsMTA4LjE1NSw2My43OTEsMTEwLjQ4OVoiIGZpbGw9IiMxZjUzNTUiLz4KICAgICAgPHBhdGggaWQ9IlBhdGhfMTQiIGRhdGEtbmFtZT0iUGF0aCAxNCIgZD0iTTc1LjE1OSw4Ny41NzFjLTQuODM4LTEuNi0zMC4wNjUtMTMuNDEzLTMwLjY5MS0xMy43NTJxLjQ3MywxLjUzNCwxLjAxNCwzLjA2MWM1LjA0MywxNi4zMjMsMTUuOCwzMS4yNzUsMTguMzA4LDMzLjYwOCw0LjgzNCw1LjE5LDE0LjI2NSw0LjY4NywyMC40NzEtLjY4MWExNy4wODcsMTcuMDg3LDAsMCwwLDQuODg1LTYuNzY0Qzg4LjkwOCwxMDEuODg0LDg4LjUsOTEuOTc1LDc1LjE1OSw4Ny41NzFaIiBmaWxsPSIjMjM2OTZjIi8+CiAgICAgIDxwYXRoIGlkPSJQYXRoXzE1IiBkYXRhLW5hbWU9IlBhdGggMTUiIGQ9Ik01OS4yNjYsMTI0LjE3MmM2LjUyNSwyLjc3OSwxNC45MzktMS41MSwxOC40My04LjkzNnMxLjUxLTE0Ljk3MS00LjEzLTE3LjM4MmMtMi44OTUtMS4xMTYtMTguMzY0LTYuMjM5LTMxLjktMTMuOTY5QzI3LjgyOCw3Ni43MzMsMTUuOTIzLDY2Ljk3NCwxMyw2OS45MDcsMTAuMDgsNzIuNiwxNy4xNSw4OC41MzUsMjguODg3LDEwMC45LDQwLjEyNSwxMTMuNzYzLDU2LjAzLDEyMy4wNTcsNTkuMjY2LDEyNC4xNzJaIiBmaWxsPSIjMjc3ZjgyIi8+CiAgICAgIDxwYXRoIGlkPSJQYXRoXzE2IiBkYXRhLW5hbWU9IlBhdGggMTYiIGQ9Ik0zMC40LDg3LjY1OGMuNzI3LDIuMDU5LDEuNTQ3LDQuMTI2LDIuNDY1LDYuMTYxLDYuMzcsMTUuODUyLDE4LjMyNSwyOS44NjcsMjEuMDEzLDMxLjk4Nyw1LjI0NSw0Ljc3NCwxNC42LDMuNSwyMC4zNDUtMi4zNjRzNi4zNTktMTMuNjM4LDEuODI4LTE3Ljc3M0M3NS42LDEwNS4yODgsMzIuOCw4OC44MjEsMzAuNCw4Ny42NThaIiBmaWxsPSIjMmY5ODljIi8+CiAgICAgIDxwYXRoIGlkPSJQYXRoXzE3IiBkYXRhLW5hbWU9IlBhdGggMTciIGQ9Ik02NC40MzYsMTM2LjQ5MWM3LjA5MS0uMTA5LDEzLjA0LTcuNDQ0LDEzLjIxNy0xNS42NDcuMTgtOC4yMjEtNC43LTE0LjI5NS0xMC44My0xNC4yMS0zLjEuMTU1LTE5LjMxNiwxLjc1Mi0zNC44Mi4xOC0xNS41NTQtLjkxOS0zMC4zOTQtNS4wMDYtMzEuODczLTEuMTQtMS41NzksMy42NDcsMTEuMzUsMTUuMzQyLDI3LjA5MywyMS44NzVDNDIuNzE4LDEzNC43NDcsNjEuMDI2LDEzNi43ODUsNjQuNDM2LDEzNi40OTFaIiBmaWxsPSIjMzZiMWI1Ii8+CiAgICAgIDxwYXRoIGlkPSJQYXRoXzE4IiBkYXRhLW5hbWU9IlBhdGggMTgiIGQ9Ik0xNDkuODc2LDEyNi42MzNjMCwyNy41NDYtMjIuMzMsMzEuMTk1LTQ5Ljg3NiwzMS4xOTVzLTQ5Ljg3Ni0zLjY0OS00OS44NzYtMzEuMTk1LDIyLjMzLTUzLjQsNDkuODc2LTUzLjRTMTQ5Ljg3Niw5OS4wODgsMTQ5Ljg3NiwxMjYuNjMzWiIgZmlsbD0idXJsKCNsaW5lYXItZ3JhZGllbnQpIi8+CiAgICAgIDxwYXRoIGlkPSJQYXRoXzE5IiBkYXRhLW5hbWU9IlBhdGggMTkiIGQ9Ik05MC40NjEsODYuNjQ5YTI5LjU0MywyOS41NDMsMCwwLDAtMTEuMSw2Ljc3NywzLjA2MSwzLjA2MSwwLDAsMS00LjI3NC00LjM4NCwzNS42MzMsMzUuNjMzLDAsMCwxLDEzLjM4MS04LjE4MSwzLjA1OSwzLjA1OSwwLDAsMSwzLjg5MiwxLjlDOTMuMSw4NC45MDgsOTAuOSw4Ni41LDkwLjQ2MSw4Ni42NDlaIiBmaWxsPSIjYWFmOWZjIi8+CiAgICAgIDxwYXRoIGlkPSJQYXRoXzIwIiBkYXRhLW5hbWU9IlBhdGggMjAiIGQ9Ik02OC45NzksMTIwLjI3OWE1LjYzOSw1LjYzOSwwLDEsMC01LjYzOS01LjYzOUE1LjYzOSw1LjYzOSwwLDAsMCw2OC45NzksMTIwLjI3OVoiIGZpbGw9IiMxMjEyMTIiLz4KICAgICAgPHBhdGggaWQ9IlBhdGhfMjEiIGRhdGEtbmFtZT0iUGF0aCAyMSIgZD0iTTEzMS43MjIsMTIwLjI3OWE1LjYzOSw1LjYzOSwwLDEsMC01LjYzOS01LjYzOUE1LjYzOSw1LjYzOSwwLDAsMCwxMzEuNzIyLDEyMC4yNzlaIiBmaWxsPSIjMTIxMjEyIi8+CiAgICAgIDxwYXRoIGlkPSJQYXRoXzIyIiBkYXRhLW5hbWU9IlBhdGggMjIiIGQ9Ik05OS40NDksMTM3LjcyM2EzMi45NjEsMzIuOTYxLDAsMCwwLDEwLjY1Ny0xLjY2NCwzMS4wNjEsMzEuMDYxLDAsMCwwLDkuMDgzLTQuOWwyLjAyNCwyLjk2OGEzNC44NSwzNC44NSwwLDAsMS05Ljg0OCw1LjYyMUEzMi40ODUsMzIuNDg1LDAsMCwxLDk5LjQ0OSwxNDEuOWEzMi44NDIsMzIuODQyLDAsMCwxLTExLjk2MS0yLjE1OCwzNS4wMDgsMzUuMDA4LDAsMCwxLTkuOC01LjYyMWwyLjAyMy0yLjk2OGEzMS4wNjcsMzEuMDY3LDAsMCwwLDkuMDgzLDQuOUEzMi45NjQsMzIuOTY0LDAsMCwwLDk5LjQ0OSwxMzcuNzIzWiIgZmlsbD0iIzEyMTIxMiIvPgogICAgPC9nPgogIDwvZz4KPC9zdmc+Cg==)

### Open Policy Containers

OPCR policy images can be loaded in over the Bundle API. The feature it documented in the [OPCR docs](https://openpolicycontainers.com/docs/opa/).

[View Details](/ecosystem/entry/ocpr)

![](/assets/images/moat-1e74c82f919bcf2de8833b0e605f8405.png)

### Moat

Moat supplies bundles to OPA to provide powerful data authorisation for Trino See [Moat Bundles](https://moat-io.github.io/moat/bundles/).

[View Details](/ecosystem/entry/moat)