Title: Add a new ABAC filter.

Proposal:

• Add an Attribute Based Access Control (ABAC) filter to the Envoy extension tree (not contrib/).
  • https://en.wikipedia.org/wiki/Attribute-based_access_control
  • ABAC functionality will be a superset of RBAC.
• Include listener, network, and HTTP filter flavors.
• Use exclusively CEL for representing match criteria.
• Support an ordered set of rules each with CEL matcher and associated terminal or nonterminal action (allow/deny, and setMetadata) with appropriate short-circuit and fall-through semantics.
• Support extensible CEL vocabularies. issue
• Expose CEL unknown_set(s) feature in metadata or FilterState to support guiding multi-pass policy enforcement.

Goals:

• Support uses cases where a company can efficiently enforce advanced access controls that contain allow and deny rules, and match traffic by composing a variety of attributes (both those that may be available in Envoy CEL today, as well as custom attributes that may be expensive/slow to obtain (e.g. via ext_proc or custom filter(s)).
  • This can be achieved through the use of multiple ABAC evaluations, with data-providing filters between, where expression evaluation can short circuit via simple/cheap attributes, and inform additional expensive attribute calculation with the unknown_set(s).
  • Pseudo-example: Ruleset intent of ALLOW if identity == 'i1' || (identity == 'i2' && attributeObtainedFromExpensiveCustomFilterLogic == 'foo')'
    • With ABAC, the company creates a filter chain of ... -> ABAC0 -> ExpensiveCustomFilter -> ABAC1 ->... where ABAC0 and ABAC1 use the same ruleset.
    • ABAC0 is able to short-circuit ALLOW all i1 traffic, short circuit DENY all traffic that doesn't have identity i1 or i2.
    • ExpensiveCustomFilter can gate its processing on the ABAC expressing an unbound/unknown attributeObtainedFromExpensiveCustomFilterLogic value (traffic from i2).
    • ABAC1 re-evaluates the ruleset after ExpensiveCustomFilter for a result.

Alternatives considered:

• Use modified RBAC for the above case.
  • RBAC only supports a single action, and no concept of rule precedence. This becomes restrictive with advanced cases where rules include interleaved ALLOW and DENY rules (e.g. because they're administered by different groups with different goals).
  • RBAC forces action determination in a single pass, it doesn't support partial evaluation with a 'calculate more costly attributes' output.
  • RBAC includes both CEL and non-CEL(essentially a custom AST) match criteria ); it is centered around roles, and doesn't treat CEL and attributes as first class citizens for matching.
• The amount of work to modify RBAC to support the above goal is significant, backward compatibility would be difficult, and the legacy non-CEL matching mechanism is inappropriate for the more powerful and flexible features we'd need to add to the filter.

htuch@ is the maintainer sponsor of this work.