About OPA

OPA is an open source, general-purpose policy engine that you can use to enforce versatile policies in a uniform way across your organization. Compared to a role-based access control (RBAC) authorization system, OPA allows you to create more fine-grained policies. For more information, see the OPA docs.

OPA policies are written in Rego. Based on the older query languages Prolog and Datalog, Rego extends support to more modern document models such as JSON.

Gloo Mesh Enterprise’s OPA integration populates an input document to use in your OPA policies. The structure of the input document depends on the context of the incoming request, described in the following table. For more information about input documents, see the OPA docs.

OPA input structureDescription
input.check_requestBy default, all OPA policies contain an Envoy Auth Service CheckRequest. This object has all the information that Envoy gathers about the request being processed. You can view the structure of this object in the attributes section of the linked Envoy doc.
input.http_requestWhen processing an HTTP request, Envoy populates this field for convenience. For the structure of this object, see the Envoy HttpRequest docs and proto files.
input.state.jwtIf you use OAuth, the token retrieved during the OIDC flow is placed into this field.

OPA with other types of external auth

The OPA external auth module can be combined with other external auth modules, such as API keys, to perform additional validation checks on incoming requests. To find an example of how to use API keys and OPA together, see API key and OPA.

The following video shows an example of using OAuth and OPA.

OPA implementation options

Gloo’s external auth service supports three main ways to implement OPA. You can also use a mix of implementations in the same cluster. Just be sure to create separate external auth policies for each implementation.

  • Default: Load the Rego rules from a Kubernetes config map as an OPA module: Choose this option for quick testing or small OPA use cases. You create your Rego rules as Kubernetes config maps in the cluster. Then, you use an external auth policy to tell the Gloo external auth service to load these rules via the OPA module. This approach can be convenient, especially if you are not familiar with administering an OPA server and do not need extended capabilities such as bundling.
  • Beta: Run an OPA server as a sidecar to the external auth service: Choose this option to manage an OPA server instance for extended capabilities such as bundling. With bundling, your Rego rules can live as a signed bundle in an external, central location, such as an AWS S3 bucket to meet your internal security requirements. This sidecar approach increases the resources needed in the external auth server pod, but works better at scale and provides more OPA-native support for teams familiar with administering an OPA server.
  • Beta: Bring your own OPA server: Choose this option to bring your own OPA server instance for extended capabilities such as bundling. Bringing your own OPA server increases the administrative complexity, but works better at scale and provides more OPA-native support for teams familiar with administering an OPA server. It also lets you take advantage of your existing OPA server configuration and enterprise OPA license.

OPA-Envoy plugin API

The OPA sidecar for the Gloo external auth server includes the OPA-Envoy plugin API. This way, you can use OPA to evaluate requests with metadata from Envoy, such as the request and response headers, body, status code, and other metadata. For more information, see the OPA docs.

Monitor your OPA environment in Grafana

Import a pre-built Grafana dashboard to visualize the metrics that the Open Policy Agent records. These metrics include information on the OPA engine performance, such as CPU and memory stats, response times, and bundle status. This feature is available for OPA version 0.58.0 or later.

To set up the dashboard, see Import the OPA dashboard.