Provide runtime.action to condition expressions

[haines]

It would sometimes be useful to be able to write a rule matching a wildcard action and use the matched action in the condition expression, e.g.

- actions:
    - "*"
  effect: EFFECT_DENY
  roles:
    - user
  condition:
    match:
      expr: R.attr.foo > (runtime.action == "bar" ? 9000 : 42)

We used to expose the input actions via request.actions but that is not suitable for this use case - you want to be able to write the condition based on the action that matched the wildcard rather than the full set of actions that were provided in the request.

We could add a field action to the cerbos.engine.v1.Runtime message, which would be populated with the action currently being evaluated by the engine.

[charithe]

There are couple of complications with this:

• Variables should be forbidden from referencing runtime.action
  • We currently evaluate variables at the beginning of a policy. If variables are allowed to reference runtime.action we'd have to re-evaluate them for each action
  • Reasoning about variables becomes quite mind bending when they change from rule to rule
• CEL doesn't have a way to lazily evaluate field accesses like runtime.effectiveDerivedRoles. So, the first time runtime.action is used we'd have to compute and sort the effective derived roles as well.

[haines]

Variables should be forbidden from referencing runtime.action

I think this is more confusing than having variables that change from rule to rule. My mental model of variables is that they are effectively macros; a variable in an expression can be expanded with its definition (and indeed this is how we do it in the query planner). As an optimization, variables that do not reference runtime.action can be precomputed in checks, but I think lazily evaluating ones that do reference it should be allowed.

Similarly I think it should be possible to reference runtime.action in derived role conditions. The use case I am thinking of is an API key which has a set of user-configurable permissions, so the principal attributes contains something like

permissions:
  "resource1:action1": true
  "resource2:action2": true
  # ...

Then I want to define a derived role like

name: permitted_api_key
parentRoles:
  - api_key
condition:
  match:
    expr: P.attr.permissions[R.kind + ":" + runtime.action]

so that I don't have to include the permissions check in a condition in every policy rule.