Proto: ext_auth_server.proto



ExtAuthServer is used configure the backend server used to enforce ExtAuthPolicies. All ExtAuthPolicies in a workspace require an ExtAuthServer to in order to function. If no ExtAuthServer is provided, a default configuration will be used. Currently Gloo Mesh only supports a single ExtAuthServer per workspace.


Select the destination that Gloo uses to externally authenticate traffic. The destination can be a Kubernetes service, such as the Gloo external auth service or your own external auth service, or a VirtualDestination. The destination cannot be an ExternalService.
  • Kubernetes service: Make sure to select the correct cluster and namespace of the external auth destination. For example, although you create this ExtAuthServer resource in the management cluster in most cases, remember that the Gloo external auth service runs in each workload cluster.
  • Virtual destination: Group up to one external auth service for each registered cluster. The external auth service names and namespaces must match on all clusters. Also, the namespaces must be enabled for Istio-injection so that the external auth pods have sidecars.
If omitted, Gloo looks for a service with the name extauth in the agent namespace in each cluster where the external auth service is deployed.

If this is set, communication to the upstream will be via HTTP and not GRPC.

Timeout for the ext auth service to respond. Defaults to 2s. For information about the value format, see the Google protocol buffer documentation.

In case of a failure or timeout querying the auth server, normally a request is denied. if this is set to true, the request will be allowed.

Set this if you also want to send the body of the request, and not just the headers.

Clear the route cache to force the external auth service to recalculate the routing decision. All cached routes are cleared if one of the following conditions is met.
1. The field is set to true.
2. The external auth service returns a HTTP 200 or gRPC 0 response code.
3. At least one authorization response header is added to the client request, or is used to alter another client request header.
The default value is false.

Sets the HTTP status that is returned to the client when there is a network error between the filter and the authorization server. The default status is HTTP 403 Forbidden. If set, this must be one of the following: - 100 - 200 201 202 203 204 205 206 207 208 226 - 300 301 302 303 304 305 307 308 - 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 421 422 423 424 426 428 429 431 - 500 501 502 503 504 505 506 507 508 510 511

Determines the API version for the ext_authz transport protocol that will be used by Envoy to communicate with the auth server. Defaults to V3. For more info, see the transport_api_version field here.

Optional additional prefix to use when emitting statistics. This allows to distinguish emitted statistics between configured ext_authz filters in an HTTP filter chain.


Configuration for buffering the request data.


Sets the maximum size of a message body that the filter will hold in memory. Envoy will return HTTP 413 and will not initiate the authorization process when buffer reaches the number set in this field. Note that this setting will have precedence over failure_mode_allow. Defaults to 4KB.

When this field is true, Envoy will buffer the message until max_request_bytes is reached. The authorization request will be dispatched and no 413 HTTP error will be returned by the filter.

When this field is true, Envoy will send the body sent to the external authorization service with raw bytes.



Sets a prefix to the value of authorization request header Path.



allowedHeaders(repeated string)

These headers will be copied from the incoming request to the request going to the auth server. Note that in addition to the user’s supplied matchers:
1. Host, Method, Path and Content-Length are automatically included to the list.
2. Content-Length will be set to 0 and the request to the authorization service will not have a message body.
headersToAdd(repeated ExtAuthServerSpec.HttpService.Request.HeadersToAddEntry)

These headers that will be included to the request to authorization service. Note that client request of the same key will be overridden.





allowedUpstreamHeaders(repeated string)

When this is set, authorization response headers that have a will be added to the original client request and sent to the upstream. Note that coexistent headers will be overridden.
allowedClientHeaders(repeated string)

When this. is set, authorization response headers that will be added to the client’s response when auth request is denied. Note that when this list is not set, all the authorization response headers, except Authority (Host) will be in the response to the client. When a header is included in this list, Path, Status, Content-Length, WWW-Authenticate and Location are automatically added.


The status of the resource after it is applied to your Gloo environment.


The most recent generation observed in the object’s metadata. If the observedGeneration does not match metadata.generation, Gloo Mesh has not processed the most recent version of this object.

Whether the resource has been accepted as valid and processed in the Gloo Mesh config translation.


Describes the transport protocol version to use when envoy connects to the ext auth server.

GLOO_MESH_AUTO0Use transport version that matches the version the default enterprise ext-auth-service uses.
ENVOY_AUTO1Use envoy’s auto transport version. This will change as envoy cycles through transport api versions.
V32Use v3 API.