MongoDB Data Plugin

Enterprise OPA supports pulling in data from MongoDB documents using periodic polling.

info

You can also query MongoDB directly from a policy at query-time using the mongodb built-in function.

Example Configuration

The MongoDB integration is provided through the data plugin, and needs to be enabled in Enterprise OPA's configuration.

# enterprise-opa-conf.yaml
plugins:
  data:
    employees.hr:
      type: mongodb
      uri: localhost:27017
      database: permissions
      collection: employees
      filter:
        organization: HR
      polling_interval: 10s
      rego_transform: data.e2e.transform

With a config like this, Enterprise OPA will retrieve the documents in the employees collection in the permissions database every 10s. The result will contain only documents containing {organization: HR} and the documents will be available to all policy evaluations under data.employees.hr.{_id}.

Configuration

Parameter	Type	Required	Default	Description
`uri`	String	Yes		The URI of the database.
`auth`	Object	No		See Auth
`canonical`	Bool	No	false	Whether to use Canonical mode or not for BSON encoding. More Details
`polling_interval`	Strong	No	30s	The interval between polling of the database.

Auth

Parameter	Type	Required	Description
`auth.auth_mechanism`	String	No	The mechanism to use for authentication. Supported values include `SCRAM-SHA-256`, `SCRAM-SHA-1`, `MONGODB-CR`, `PLAIN`, `GSSAPI`, `MONGODB-X509`, and `MONGODB-AWS`. More details.
`auth.auth_mechanism_properties`	Object	No	Additional configuration options for certain mechanisms. More Details
`auth.auth_source`	String	No	The name of the database to use for authentication. More Details.
`auth.username`	String	No	The username for authentication.
`auth.password`	String	No	The password for authentication.
`auth.password_set`	Bool	No	For GSSAPI, this must be true if a password is specified, even if the password is the empty string, and false if no password is specified, indicating that the password should be taken from the context of the running process. For other mechanisms, this field is ignored.

See links below to the MongoDB docs for more information on some of the options:

Database, Collection and Find Options

Parameter	Type	Required	Description
`database`	String	Yes	The name of the database.
`collection`	String	Yes	The name of the collection in the database to fetch from.
`filter`	Object	Yes	The document describing query conditions for the operation. More Details
`find_options`	Object	No	The document describing extra query options. More Details

Data Transformations

The rego_transform attribute specifies the path to a rule used to transform data pulled from MongoDB into a different format for storage in Enterprise OPA.

rego_transform policies take incoming messages as JSON via input.incoming and returns the transformed JSON.

Example

Starting with the Enterprise OPA configuration above and the example Data

[
  {
    "_id": {
      "$oid": "6520a3db73b2495b371c6eb3"
    },
    "country": "US",
    "employeeID": "1276",
    "name": "Jane Doe",
    "organization": "HR"
  },
  {
    "_id": {
      "$oid": "652715d4da89b61eaca5cab9"
    },
    "country": "US",
    "employeeID": "1337",
    "name": "Alice Abramson",
    "organization": "Product"
  },
  {
    "_id": {
      "$oid": "65271608da89b61eaca5caba"
    },
    "country": "DE",
    "employeeID": "976",
    "name": "Bob Branson",
    "organization": "HR"
  }
]

Our data.e2e.transform policy is:

package e2e

import rego.v1

transform := {c: {e.employeeID: e.name | e := input.incoming[_]; e.country == c} | c := input.incoming[_].country}

Then the data retrieved by the S3 plugin would be transformed by the above into:

curl "${ENTERPRISE_OPA_URL}/v1/data/employees/hr?pretty"
{
  "result": {
    "DE": {
      "976": "Bob Branson"
    },
    "US": {
      "1276": "Jane Doe",
    }
  }
}

Example Configuration​

Configuration​

Auth​

Database, Collection and Find Options​

Data Transformations​

Example​