Role Based Access Control
The Role Based Access Control (RBAC) filter checks if the incoming request is authorized or not. Unlike external authorization, the check of RBAC filter happens in the Envoy process and is based on a list of policies from the filter config.
The RBAC filter can be either configured as a network filter, or as a HTTP filter or both. If the request is deemed unauthorized by the network filter then the connection will be closed. If the request is deemed unauthorized by the HTTP filter the request will be denied with 403 (Forbidden) response.
The RBAC filter checks the request based on a list of policies. A policy consists of a list of permissions and principals. The permission specifies the actions of the request, for example, the method and path of a HTTP request. The principal specifies the downstream client identities of the request, for example, the URI SAN of the downstream client certificate. A policy is matched if its permissions and principals are matched at the same time.
Instead of specifying policies, the RBAC filter can also be configured with the matching API. Network inputs are available for both RBAC network filter and HTTP filter, and HTTP inputs are only available in HTTP filter.
Shadow Policy and Shadow Matcher
The filter can be configured with a shadow policy or a shadow matcher that doesn’t have any effect (i.e. not deny the request) but only emit stats and log the result. This is useful for testing a rule before applying in production.
In addition to the pre-defined permissions and principals, a policy may optionally provide an
authorization condition written in the Common Expression Language. The condition specifies an extra
clause that must be satisfied for the policy to match. For example, the following condition checks
whether the request path starts with
call_expr: function: startsWith args: - select_expr: operand: ident_expr: name: request field: path - const_expr: string_value: /v1/
Envoy provides a number of request attributes
for expressive policies. Most attributes are optional and provide the default
value based on the type of the attribute. CEL supports presence checks for
attributes and maps using
has() syntax, e.g.