Proposal - Filter conditions as OPA Rego expressions

[mariusdanciu]

Problem description

Currently Praxis provide a simple but powerful enough mechanism to express when a Filter is invoked for request and response paths via the Conditions enum:

pub enum Condition {
    /// Execute the filter only if the predicate matches.
    When(ConditionMatch),

    /// Skip the filter if the predicate matches.
    Unless(ConditionMatch),
}
...
pub struct ConditionMatch {
    /// Request URI must match this exact path.
    #[serde(default)]
    pub path: Option<String>,

    /// Request URI must start with this prefix.
    #[serde(default)]
    pub path_prefix: Option<String>,

    /// Request method must be one of these (case-insensitive).
    #[serde(default)]
    pub methods: Option<Vec<String>>,

    /// Headers that must be present and match.
    #[serde(default)]
    pub headers: Option<HashMap<String, String>>,
}

However admins would sometimes need a more flexible mechanism to allow them to express more complex logic (conjunctions, disjunctions, negations etc) for deciding when a filter should be used.

Proposal

The Condition enum support a 3-rd type of predicate "Rego" such as:

Conceptual example

pub enum Condition {
    /// Execute the filter only if the predicate matches.
    When(ConditionMatch),

    /// Skip the filter if the predicate matches.
    Unless(ConditionMatch),

    /// Evaluate rego expressions for request and response
    RegoExpression(RegoDefinition),
}

...

#[derive(Debug, Clone)]
pub struct RegoDefinition {
    pub request_predicate: String,
    pub response_predicate: String
}

Of course we would want to cache the "compiled" rego script and not parse it on each request. However this is an optimization detail out of the scope of this proposal. This also depends on what rego rust crate will be used (Regorus might be a good choice). But each crate uses it own API and ideally the Praxis structures should be decoupled from the underlying rego crates, so further abstraction would be needed.

[shaneutt]

Currently Praxis provide a simple but powerful enough mechanism to express when a Filter is invoked for request and response paths via the Conditions enum.
However admins would sometimes need a more flexible mechanism to allow them to express more complex logic (conjunctions, disjunctions, negations etc) for deciding when a filter should be used.

Your assessment of the problem is spot on: Praxis is currently not nearly expressive enough in its filter invocation conditionals.

Filter conditions as OPA Rego expressions: The Condition enum support a 3-rd type of predicate "Rego"

The underlying need is valid, but it's not clear to me that OPA Rego is the right solution for Praxis.

Rego presents some significant challenges:

• Philosophy Mismatch - Praxis currently approaches filter invocation conditionals as a combinatorial logic problem, Rego approaches it as a policy evaluation problem.
• Performance Mismatch - Praxis' existing filter invocation conditionals are intentionally lightweight, as they are executed during request processing. The hot path needs to be optimized and the current approach is nanosecond scale. Rego appears as though it would operate in the microsecond scale for requests that hit it, adding significant latency.
• Dependency Problem - Rego is a large dependency to pull in for such a focused use. It's a full-featured policy language designed for authorization decisions, and (at least at first) we would be utilizing it for relatively simple purposes.
• Operational Burden - Configuration authors would need to learn the syntax and maintain rules in it, and those rules may not always be as axiomatic as simple boolean logic for future config readers. There could be complexity here that would make it easier to botch a configuration.
• Security Concerns
  • Unsafe Code - Praxis philosophy is to avoid unsafe code if at all possible, and if a compromise ever does need to be made it needs to be as confined as we can possible make it. Regorust in particular wraps the C++ library via FFI, which in addition to making it heavyweight for the problem domain also means we inherent risk from that codebase written in a memory unsafe language.
  • Embedded Scripting Language - Having work in proxy technologies for a long time, embedding scripting languages into proxy servers has been a top contributor to critical security vulnerabilities. While Rego is no Lua, this kind of thing always gives me pause.

To be clear: I'm not definitively saying no. We should discuss this further. Please do, however, consider the above concerns and let me know your thoughts on them? 🤔

I want to brainstorm with you a bit, take a look at the problem from another angle. We currently lack the ability to express:

• OR: "execute if path starts with /api OR method is POST"
• Nested NOT: "execute unless (path is /health AND method is GET)"
• Complex combinations: "execute if (method is POST AND path prefix /api) OR header X-Admin is present"

These have strong potential value, especially the combinators. For example we could add OR conditions:

conditions:
  - any:
      - when:
          path_prefix: "/api"
      - when:
          methods: ["POST"]

Or nested NOT conditions:

conditions:
  - not:
      when:
          path_prefix: "/health"
          methods: ["GET"]

This would be a more natural extension of the existing conditional surface, requires zero dependencies, and keeps it all in the nanosecond operational space. Would this be adequate for our practical needs? LMKWYT 🤔

[mariusdanciu]

@shaneutt these are valid concerns. Let me address some

Philosophy Mismatch - Praxis currently approaches filter invocation conditionals as a combinatorial logic problem, Rego approaches it as a policy evaluation problem.

The current conditional support doesn't allow expressing complex predicates and all logical operations. To allow admins to do that without rebuilding their proxy implies a DSL language (Rego, CEL etc).

Performance Mismatch - Praxis' existing filter invocation conditionals are intentionally lightweight, as they are executed during request processing. The hot path needs to be optimized and the current approach is nanosecond scale. Rego appears as though it would operate in the microsecond scale for requests that hit it, adding significant latency.

Defining complex predicates expressed as yaml structures is not that far away from a DSL language. A DSL usually compiles into fast ASTs and the performance is not at all bad. For rego I do see micro-seconds evaluations times but obviously it all depends on how large the rego code becomes. With crates like regorus it is still Rust code that evaluates the AST. I don't see why in general this code would be slower that the internal bespoke code for evaluating requests against config yaml structures. Nonetheless benchmarking the two options would be interesting.

Dependency Problem - Rego is a large dependency to pull in for such a focused use. It's a full-featured policy language designed for authorization decisions, and (at least at first) we would be utilizing it for relatively simple purposes.

Yes rego can do a little more than evaluating boolean expressions. However it is fairly widely adopted and many admins already understand it from auth policies. Re-using this knowledge and reinventing something different can be quite beneficial. The scope for rego use for filter conditions seems quite intuitive to me and understandable by admins.

Operational Burden - Configuration authors would need to learn the syntax and maintain rules in it, and those rules may not always be as axiomatic as simple boolean logic for future config readers. There could be complexity here that would make it easier to botch a configuration.

I don't see this as a burden, quite the opposite. Because this is a language already used by admins in auth policies in other systems the adoption would be quite natural. Not to mention that the is very intuitive.

Security Concerns
Unsafe Code - Praxis philosophy is to avoid unsafe code if at all possible, and if a compromise ever does need to be made it needs to be as confined as we can possible make it. Regorust in particular wraps the C++ library via FFI, which in addition to making it heavyweight for the problem domain also means we inherent risk from that codebase written in a memory unsafe language.

I apologies for mentioning Regorust. I really meant Regorus which is 100% Rust (I was looking at both and pasted the wrong one) . Not much unsafe code. I am fully aware of Rust strengths as I've been using Rust for more than 7 years.

Embedded Scripting Language - Having work in proxy technologies for a long time, embedding scripting languages into proxy servers has been a top contributor to critical security vulnerabilities. While Rego is no Lua, this kind of thing always gives me pause.

I can understand the hesitation.

I want to brainstorm with you a bit, take a look at the problem from another angle. We currently lack the ability to express:
OR: "execute if path starts with /api OR method is POST"
Nested NOT: "execute unless (path is /health AND method is GET)"
Complex combinations: "execute if (method is POST AND path prefix /api) OR header X-Admin is present"

Technically this is of course possible, but I have a few observations:

1. This has the potential to be more verbose than rego expressions. Comparing:

conditions:
  - any:
      - when:
          path_prefix: "/api"
      - when:
          methods: ["POST"]

with

conditions:
   - rego: 
         allow {
            any([input.request.path_prefix == "/api", input.request.method == "POST"])
         }

The rego syntax seems to me easier to reason and maintain.

Personally I find rego rules suitable for filter conditions especially from and admin standpoint, but If Rego seems too much what do you think about CEL ? (there are rust crates for cel as well)

[shaneutt]

@shaneutt these are valid concerns. Let me address some

Philosophy Mismatch - Praxis currently approaches filter invocation conditionals as a combinatorial logic problem, Rego approaches it as a policy evaluation problem.

The current conditional support doesn't allow expressing complex predicates and all logical operations. To allow admins to do that without rebuilding their proxy implies a DSL language (Rego, CEL etc).

I agree that there's a visible gap, but note that I have a natural tendency to hesitate in picking a solution for a problem that doesn't have documented end-user requirements driving it. Whatever we choose, let's make sure we're being very deliberate about it and that we understand and document the goals, motivation and user stories (the "What?" and "Why?").

Performance Mismatch - Praxis' existing filter invocation conditionals are intentionally lightweight, as they are executed during request processing. The hot path needs to be optimized and the current approach is nanosecond scale. Rego appears as though it would operate in the microsecond scale for requests that hit it, adding significant latency.

Defining complex predicates expressed as yaml structures is not that far away from a DSL language. A DSL usually compiles into fast ASTs and the performance is not at all bad. For rego I do see micro-seconds evaluations times but obviously it all depends on how large the rego code becomes. With crates like regorus it is still Rust code that evaluates the AST. I don't see why in general this code would be slower that the internal bespoke code for evaluating requests against config yaml structures. Nonetheless benchmarking the two options would be interesting.

Direct field matching on typed Rust structs skips input construction, runtime invocation, variable lookup and AST traversal. Those steps are on the hot path and are not free. The gap narrows for complex conditions but doesn't close. As you suggest though, it is conceivable that having something more expressive could become a necessity for users in time. Your plan to benchmark them seems like the exact right thing to do to add more concrete information to the theoretical.

Dependency Problem - Rego is a large dependency to pull in for such a focused use. It's a full-featured policy language designed for authorization decisions, and (at least at first) we would be utilizing it for relatively simple purposes.

Yes rego can do a little more than evaluating boolean expressions. However it is fairly widely adopted and many admins already understand it from auth policies. Re-using this knowledge and reinventing something different can be quite beneficial. The scope for rego use for filter conditions seems quite intuitive to me and understandable by admins.

Not all proxy operators are OPA-savvy, but this is a valid point: familiarity is an important criteria to be considering as we continue to discuss.

Security Concerns
Unsafe Code - Praxis philosophy is to avoid unsafe code if at all possible, and if a compromise ever does need to be made it needs to be as confined as we can possible make it. Regorust in particular wraps the C++ library via FFI, which in addition to making it heavyweight for the problem domain also means we inherent risk from that codebase written in a memory unsafe language.

I apologies for mentioning Regorust. I really meant Regorus which is 100% Rust (I was looking at both and pasted the wrong one) . Not much unsafe code.

Oh, yes, this is much better. Looking over Regorus and digging through the code a bit this gives me a lot less heebie-jeebies. A bit more review needed, but this may resolve the original concern.

Personally I find rego rules suitable for filter conditions especially from and admin standpoint, but If Rego seems too much what do you think about CEL ? (there are rust crates for cel as well)

CEL is a better fit than Rego for Praxis: it's lightweight, purpose-built for inline-expressions and people coming from Envoy will already be familiar.

---

I appreciate your thoughts and considerations on this. 🖖

In the spirit of brainstorming, I would also like to consider a third option that may thread the needle: a compile-to-native expression syntax. A thin parser (using something like winnow, ~30KB) that runs once at config load, compiles an expressive string into native condition combinators, then discards the parse tree. For example:

conditions:
  - expr: 'path_prefix("/api") && (method("POST") || header("x-admin") == "true")'

At runtime on the hot-path this would produce the same direct conditions we have today (with more added), but without an interpretation layer and evaluation runtime. Not having a runtime would reduce the security risks and my unease I mentioned due to the history of such things in proxy tech: validation would happen at config load with clear parse errors.

[mariusdanciu]

Parser combinators are a technique I used extensively 10+ years ago (in Scala and Java) to build DSLs and it is my preferred parsing technique. But using parser combinator still has two stages at minimun:

• parsing produces and internal structure (essentially an AST since boolean expression could be arbitrary nested). Done once per config load.
• use that internal structure for the actual evaluation during runtime requests But yes the DSL functions like path_prefix, method etc would have direct Rust native functions correspondence used at runtime so it does not need the rego's input object as properties. The rust functions have direct native access to the request object.

I do like the conciseness of the boolean expression. My initial though was to avoid inventing a new DSL since it is likely the admins are already familiar with rego or cel. On the other hand a boolean expression language is fairly easy to understand.

[shaneutt]

Appreciate the feedback 👍

More to think about and consider 🤔

[twghu]

The idea appealing. It allows for greater expressivity.

When I read this proposal I thought hmm Lua, but that can be a security issue. A constrained vocabulary for defining behavoir is less risky.

While the proposal is a great idea, the choice of any C++/C FFI call is "problematic" for Rust. Avoiding any FFI calls to any c/c++ code is .... preferable. Exceptions in C++ code are a pain and bad code causing a SEGV for instance won't be "caught" by default the Rust main. There is cxx which seems to cater for "wrapping" c++ exceptions.

These concerns aside, increasing request / response latency or at least exec cpu/mem usage has been ... "problematic" for other proxies.

While a workaround for related performance issues and attack surfaces can be implemented, it's probably a feature that can be refined and optimised for a subsequent release with detailed consideration for policies.

[mariusdanciu]

While the proposal is a great idea, the choice of any C++/C FFI call is "problematic" for Rust. Avoiding any FFI calls to any c/c++ code is .... preferable. Exceptions in C++ code are a pain and bad code causing a SEGV for instance won't be "caught" by default the Rust main. There is cxx which seems to cater for "wrapping" c++ exceptions.

@twghu there is no FFI proposal here. Regorus crate (not RegoRust) is fully Rust as I mentioned in my reply above. I fully agree that FFI would be problematic and I'd never propose such path.

These concerns aside, increasing request / response latency or at least exec cpu/mem usage has been ... "problematic" for other proxies.

As I mentioned above I'm not convinced that regorus crate rego AST evaluation is effectively less performant than internal code evaluating config predicates for conditions. But of course it depends how large and complex the script is. The same performance concern is for auth policies and still this is widely used.

[shaneutt]

@mariusdanciu, @twghu and myself all seem to generally agree on the problem identified here and that we are inclined to solve it.

We don't have alignment yet on how to solve the gap, but we have a path forward via prototyping, testing and benchmarking that I'm confident will get us there.

So given the strong signal here I'm going to signoff on this discussion and say this is ready to move to a full-on proposal.

Thank you for your efforts here @mariusdanciu! Please feel free to create an epic to track this (or I can if you prefer), and go to a proposal using that issue number. 🖖

[mariusdanciu]

Thank you very much @shaneutt and @twghu for taking your time and provide such good feedback. I can create an epic that summarizes the options proposed here.