OpenPolicyAgent integration

Slack Docker Pulls


Alluxio can integrate with OPA and delegate all permission checks to the OPA.

Architecture overview

Every Alluxio client will talk to the Alluxio Master for metadata operations. If Alluxio OPA integration is enabled,

  • Alluxio master delegates its permission check to the OPA.
  • Alluxio master fully trusts the access permission evaluation result from the OPA.
  • OPA is expected to be deployed as a daemon, Alluxio master talks to OPA via REST API (
  • It is better to deploy OPAs as sidecar which can minimize the network cost. The OPAs can periodically download the policies or json config files.
  • An embedded cache in Alluxio master can further reduce the traffic between Alluxio master and OPA.
  • Alluxio Master supports setting the policy path in one OPA server per mount.
  • So far only styra OPA is certified.


Switch to turn on/off OPA:

  • : Turn on authorization
  • : Whether to enable using authorization plugins such as OPA.
  • : The plugin name, so far always be “default-opa-1.0”.
  • : The plugin path of the configured plugin. By default the plugin path of OPA is “/opt/alluxio/lib”.

All masters can share the same OPA or use its dedicated sidecar OPA.

  • : the OPA daemon port.
  • : the OPA daemon address.

Alluxio master OPA integration supports with or without SSL. The configuration without SSL should be used for testing purpose only.

  • : Whether to enable SSL.
  • : CA path for opa connection.
  • : CERT path for opa connection.
  • : Private key path for opa connection.

The OPA check granularity:

  • Whether the access control per file, otherwise per directory. Default(true) is checking per file. If the cost of checking per file is too high, it can be changed to check per directory.

The retry times on network error:

  • times of retry on network error.

Policy path per mount

By default, the OPA policy path is determined by the configuration property To specify another policy path, add the following option when mounting:

./bin/alluxio fs mount --option /s3 s3://alluxio-bucket

Message Format

Information Exchanged

The request message sent to OPA is in json format. Following information would be included:

  • user: uid, gids
  • resource
    • ufs path
    • owner user
    • owner group
    • permissions
  • action: required actions, // can be “ALL”, “READ”, “WRITE”, “EXECUTE”, “READ_EXECUTE”, “WRITE_EXECUTE”

The response message from OPA is in json format

  • allow: true/false
  • message: “anything from OPA”

Request Example

  "input": {
    "user": {
      "uid": "user1",
      "gid": [
    "resource": {
      "remote_path": "s3://my-bucket/path",
      "user": "alluxio",
      "group": "alluxio",
      "permissions": {
        "group": "---",
        "other": "---",
        "user": "rwx"
    "action": "EXECUTE".   // can be "ALL", "READ", "WRITE", "EXECUTE", "READ_EXECUTE", "WRITE_EXECUTE"

Response Example

  "result": {
    "allow": true,
    "message": "anything"

Alluxio Cache Mechanism

Alluxio master has an embedded cache to reduce the number of duplicate permissions checks. For example, it is possible for a user to check a single file’s permission multiple times within a second. The cache stores the initial response sent from OPA and reuses the permission result for a specified duration. The cache capacity and duration are controlled by:

  • Record cache time in seconds.
  • Cache capacity.