About
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. For an overview of OPA, review the following video.
OPA input structure
The Solo Enterprise for kgateway 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 implementation options
The Solo Enterprise for kgateway external auth service supports the following 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 AuthConfig resource to tell the Solo Enterprise for kgateway 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 OPA with Rego rules in config maps.
Option 2: Bring your own OPA server
- 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 that are familiar with administering an OPA server. It also lets you take advantage of your existing OPA server configuration, such as for bundling and caching, and your own enterprise OPA license.
- For more information, see Bring your own OPA server.