You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Title: Attribute aliasing Description:
Often times, control planes and higher layers expose user friendly attributes that do not map directly to an Envoy attribute. e.g., source.foo that may be obtained from filter_state['com.blah']['scooby']. In other cases, there are naming skews. e.g., envoy's attribute connection.requested_server_name is referred to in Istio or other places as connection.sni. source.address in Envoy is source.ip in some other places.
Where does this become a problem?
Imagine that the higher level API is exposing a CEL expression that can be crafted by the end user. Say the end user's expression is source.ip != 1.1.1.1. This wont evaluate within Envoy because there is no source.ip attribute. The control plane is now forced to either do a clunky search and replace of strings like source.ip, source["ip"], etc. to source.address. This is not only clunky but also very error prone.
Another area where this is a problem is in ext_proc. we have forward_attributes field in the ext_proc. Users may say forward source.foo (a user friendly attribute exposed by the higher level APIs). They may write their ext_proc servers to expect this exact attribute in the ProcessingRequest. However, if the control plane were to replace source.foo with filter_state[com.blah][scooby], the attribute in the ProcessingRequest will be filter_state[com.blah][scooby] and not source.foo. The ext_proc server will fail if it depends on this attribute for its processing.
To help both of these scenarios, we need some form of custom attribute provider in Envoy wherein one could define the attribute name and the source for these attributes. for example a filter configuration could be like:
Then in the RBAC filter's CEL expression or in ext_proc, whenever the user specifies an attribute like source.foo that is not native to Envoy, this attribute provider class if present is invoked to return the appropriate value.
The text was updated successfully, but these errors were encountered:
Similar but not the same. My proposal is dumber and doesnt involve any code by the Envoy user. Just a definition of equivalence mappings from attributeA to attributeB.
Title: Attribute aliasing
Description:
Often times, control planes and higher layers expose user friendly attributes that do not map directly to an Envoy attribute. e.g., source.foo that may be obtained from filter_state['com.blah']['scooby']. In other cases, there are naming skews. e.g., envoy's attribute connection.requested_server_name is referred to in Istio or other places as connection.sni. source.address in Envoy is source.ip in some other places.
Where does this become a problem?
Imagine that the higher level API is exposing a CEL expression that can be crafted by the end user. Say the end user's expression is
source.ip != 1.1.1.1
. This wont evaluate within Envoy because there is no source.ip attribute. The control plane is now forced to either do a clunky search and replace of strings likesource.ip
,source["ip"]
, etc. tosource.address
. This is not only clunky but also very error prone.Another area where this is a problem is in ext_proc. we have forward_attributes field in the ext_proc. Users may say forward source.foo (a user friendly attribute exposed by the higher level APIs). They may write their ext_proc servers to expect this exact attribute in the ProcessingRequest. However, if the control plane were to replace source.foo with
filter_state[com.blah][scooby]
, the attribute in the ProcessingRequest will be filter_state[com.blah][scooby] and not source.foo. The ext_proc server will fail if it depends on this attribute for its processing.To help both of these scenarios, we need some form of custom attribute provider in Envoy wherein one could define the attribute name and the source for these attributes. for example a filter configuration could be like:
Then in the RBAC filter's CEL expression or in ext_proc, whenever the user specifies an attribute like source.foo that is not native to Envoy, this attribute provider class if present is invoked to return the appropriate value.
The text was updated successfully, but these errors were encountered: