Envoy ext_authz filter¶
The Envoy ext_authz filter is an architecture component that allows an external service to handle authorization checks for a proxy.^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md] It serves as a bridge to integrate custom authorization systems, such as those within an Istio Service mesh, by delegating the decision to allow or deny a request to a remote provider.^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md]
Communication Protocols¶
The filter supports the standard authorization APIs defined by Envoy, enabling communication via either HTTP or gRPC (versions v2 and v3).^[400-devos__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md]
Behavior and Logic¶
When the external authorization server receives a check request, it evaluates the request against its configured logic.^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md]
- Allow Conditions: A common implementation, such as the example provided for Istio, allows traffic if the request includes a specific header (e.g.,
x-ext-authz: allow) or if the source workload's service account matches a permitted value (e.g.,a).^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md] - Denial Conditions: If the validation criteria are not met, the server denies the request.^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md]
- Response Headers: The filter manages headers to indicate the outcome, such as
x-ext-authz-result: allowedorx-ext-authz-check-result: denied, often utilizing the standard HTTP 200 OK and 403 Forbidden status codes respectively^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md].
Advanced Features¶
External authorization servers can interact with the request headers in advanced ways beyond simple acceptance or rejection^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md]:
- Request Reflection: The server may add a header (e.g.,
x-ext-authz-check-received) containing a dump of the original check request it received. This is useful for debugging and verifying that the filter is sending the correct data to the authorization service^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md]. - Header Manipulation: The server can dynamically add or override existing headers in the user request based on the authorization logic (e.g., setting
x-ext-authz-additional-header-override).^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md]
Related Concepts¶
- Istio
- [[gRPC]]
- Service Mesh
Sources¶
^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__extauthz__README.md]