This feature makes it possible to delegate authorization decisions to an external service and also makes the request context available to the service. The request context contains information such as the source of a network activity, destination of a network activity, the network request (eg. http request). All this information can be used by the external service to make an informed decision about the fate of the incoming request received by Envoy.

plugin extends OPA with a gRPC server that implements the Envoy External Authorization API. You can use this version of OPA to enforce fine-grained, context-aware access control policies with Envoy without modifying your microservice.

In addition to the Envoy sidecar, your application pods will include an OPA-Envoy sidecar. When Envoy receives API requests destined for your microservice, it checks with OPA to decide if the request should be allowed.

Envoy External Authorization Flow

If the configuration does not specify the path field, envoy/authz/allow will be considered as the default policy decision path. data.envoy.authz.allow will be the name of the policy decision to query in the default case.

The dry-run parameter is provided to enable you to test out new policies. You can set dry-run: true which will unconditionally allow requests. Decision logs can be monitored to see what “would” have happened. This is especially useful for initial integration of OPA or when policies undergo large refactoring.

The enable-reflection parameter registers the Envoy External Authorization gRPC server with reflection. After enabling server reflection, a command line tool such as can be used to invoke RPC methods on the gRPC server. See Interacting with the gRPC server section for more details.

See the following pages on for more information on external authorization:

• Network and for details on configuring the External Authorization filter.