OPA
Enforce Open Policy Agent (OPA) policies for more fine-grained access control.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 Platform'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 structure | Description |
|---|---|
input.check_request |
By 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_request |
When 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.jwt |
If 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 Platform'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.