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. For an overview of OPA, review the following video.

OPA input structure

Gloo Gateway’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 implementation options

The Gloo Gateway 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 AuthConfig resources for each implementation.

Option 1: Load the Rego rules from a Kubernetes config map as an OPA module.

  • The default option, good for starting out, quick testing, and 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 Gateway 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.
    • For more information, see the guide.

    Option 2: Run an OPA server as a sidecar to the external auth service.

    • A beta option good for larger use cases where you don’t want to deploy the OPA server yourself.
    • Extended the available OPA capabilities for use cases such as bundling or caching. 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.
      • For more information, see the guide.

      Option 3: Bring your own OPA server.

      • A beta option good for larger use cases where you want to deploy your own OPA server.
      • 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 such as for bundling and caching, as well as your own enterprise OPA license.
        • For more information, see the guide.

        OPA-Envoy plugin API

        The OPA sidecar for the Gloo Gateway 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.