v1.24.7

This patch contains a new optional field for Batch Query API requests: common_input.
This field allows factoring out common top-level keys in an input object, which can greatly reduce request sizes in some cases.

Here is an example:

{
  "inputs": {
    "A": {
      "user": "alice",
      "action": "write",
    },
    "B": {
      "user": "bob"
    },
    "C": {
      "user": "eve"
    }
  },
  "common_input": {
    "action": "read",
    "object": "id1234"
  }
}

The above request using common_input is equivalent to sending this request:

{
  "inputs": {
    "A": {
      "user": "alice",
      "action": "write",
      "object": "id1234"
    },
    "B": {
      "user": "bob",
      "action": "read",
      "object": "id1234"
    },
    "C": {
      "user": "eve",
      "action": "read",
      "object": "id1234"
    }
  }
}

Conflict resolution

In cases where the types are both JSON Objects, the objects' top-level keys will be merged non-recursively.
In the event of a conflict where both common_input and the per-query input have the same key, the per-query input's key/value pair is used, as shown in the earlier example where common_input provides the "action": "read" key/value pair, and query "A" provides "action": "write" for the same top-level key/value pair.

In cases where the common_input's type conflicts with that of the per-query input, the per-query input value is used.

Example:

{
  "inputs": {
    "A": [1, 2, 3]
  },
  "common_input": {
    "foo": "bar"
  }
}

The above example is equivalent to the following request, because the input type overrides:

{
  "inputs": {
    "A": [1, 2, 3]
  }
}

v1.24.6

This patch contains optimizations and bugfixes for the Batch Query API when used with OPA authorization policies.

v1.24.5

This patch contains optimizations for the Batch Query API, and also updates the Regal version used in Enterprise OPA to version v0.25.0.

Extra tools in debug image

The -debug container image now contains a number of useful helper utilities to aid in debugging problems in your deployments.
When running docker run -it --entrypoint=sh ghcr.io/styrainc/enterprise-opa:1.24.5-debug or docker exec -it <your-running-debug-container> sh, you will find

• busybox
• curl
• grpcurl
• dig
• htop
• ping
• kafkacat
• strace
• tcpdump
• ldapsearch

Binary name in all images

When using the container image in your Dockerfile, or manually constructed docker run calls, you can now refer to the Enterprise OPA binary via /bin/eopa, /bin/opa and /opa; or just use opa or eopa for convenience.

v1.24.4

This patch contains experimental features for logging intermediate evaluation results. This feature is not generally available at this time, and is disabled during normal use.

v1.24.3

This release updates Enterprise OPA to allow for environment variable substitution for the config produced by the discovery bundle. This release also updates some dependencies.

For example, with the environment variable ENV1=test1, and this config is used via discovery:

bundle:
    name: ${ENV1}
decision_logs: {}
status: {}

Enterprise OPA would interpret the configuration like so:

bundle:
    name: test1
decision_logs: {}
status: {}

v1.24.2

This release updates the OPA version used in Enterprise OPA to v0.67.1, which includes a bugfix for chunked request handling.

v1.24.1

This release fixes a regression in the Enterprise OPA CLI help text on some commands, and includes several updates to our dependencies.

v1.24.0

This release updates the OPA version used in Enterprise OPA to v0.67.0, and updates Regal to v0.24.0

The OPA version bump includes max request body size limits (a potentially breaking change for clients who use enormous request sizes), optimizations around request handling, and improved performance under load for gzipped requests.

v1.23.0

It also updates the OPA version used in Enterprise OPA to v0.66.0, and brings in various dependency bumps.

The OPA version dump includes memory usage improvements when loading gigantic bundles.

v1.22.0

This release includes an new Apache Pulsar data source, a Bulk Eval HTTP API for evaluating a policy with multiple inputs in one request, and performance improvements when loading large bundles.

It also updates the OPA version used in Enterprise OPA to v0.65.0, and brings in various dependency bumps.

Pulsar Data Source

Enterprise OPA can now subscribe to Apache Pulsar topics:

# enterprise-opa.yaml
plugins:
  data:
    users:
      type: pulsar
      url: pulsar://pulsar.corp.com:6650
      topics:
      - users
      rego_transform: "data.pulsar.transform"

See the docs for more information.

Bulk HTTP API

You can now do multiple policy evaluations in one request:

POST /v1/batch/data/policy/allow
{
  "inputs": {
    "id-1": {
      "user": "alice",
      "action": "read",
      "resource": "book"
    },
    "id-2": {
      "user": "alice",
      "action": "create",
      "resource": "book"
    },
    "id-3": {
      "user": "alice",
      "action": "delete",
      "resource": "book"
    }
  }
}

The response looks like this:

{
  "responses": {
    "id-1": {
      "result": true
    },
    "id-1": {
      "result": true
    },
    "id-3": {
      "result": false
    },
  }
}

It supports the standard query parameters (like pretty, metrics, strict-builtin-errors).

Very large bundles performance

Previously, activating a bundle did some unneeded work.
It became apparent, and problematic, when using very large bundles (1+ GB).
The issue has been fixed, leading to noticable performance improvements when using very large bundles.