Authorization decides what an already-identified caller is allowed to do. Arion offers three ways to make that decision in the request path, and picking the right one is mostly a question of how much context the decision needs.
The three options
RBAC is a set of declarative allow/deny policies evaluated in-process against connection and request properties — source IP, destination port, SNI at the network level; headers, method and path at the HTTP level. It is the fastest option and supports a per-route override, but it cannot reason about anything beyond those properties. Reach for it for IP allowlists, blocking paths, or coarse header-based rules. See RBAC.
Cedar policies evaluate a real policy language in-process against a richer picture of the request: the JWT principal, the HTTP method, path and query, and the token's claims. Policies are auditable text (permit/forbid statements) with deny-by-default semantics, so they suit per-user and per-client rules like "this service may only GET under /reports". See Cedar policies.
Your own extension is the route when the decision needs data Arion does not have — a database lookup, a quota service, an entitlements API. Write it as an ext_proc server that Arion calls over gRPC, or as a WASM filter running inside the proxy. Both can inspect the request and reply with a direct response (for example a 403) before anything reaches the backend.
Comparison
| Approach | Decision model | Runs | Per-route control | When to pick |
|---|---|---|---|---|
| RBAC | Allow/deny policies | In-process | Override or disable per route | Fast, coarse rules on IPs, ports, SNI, headers, method and path. |
| Cedar | Policy language | In-process | One policy set per filter chain | Identity-aware rules over JWT claims and request context, kept as reviewable policy text. |
| ext_proc / WASM | Your code | Sidecar gRPC server, or WASM in-process | Per-route override (ext_proc) | Decisions that need external data or logic no built-in filter expresses. |
What about ext_authz?
Envoy's ext_authz filter (HTTP and network) is not supported today — a configuration that references it is refused at startup. The supported path for external authorization is an ext_proc server or a WASM filter, which cover the same "call my service before routing" pattern.
Layering
The options compose along the filter chain, and each filter only sees what ran before it. A common arrangement: network RBAC drops unwanted sources at accept time, JWT authentication establishes who is calling, then Cedar (or HTTP RBAC) decides what that caller may do. Put authentication before authorization — Cedar reads the claims that the JWT filter validated.
Key terms
- Principal — who is asking: an IP, a header value, or a JWT subject.
- Policy — a named rule that permits or denies a (principal, request) pair.
- Deny by default — in Cedar, anything not explicitly permitted is forbidden; in RBAC, the
actiondecides whether matching means allow or deny.
Continue with RBAC for the declarative rules, Cedar policies for the policy language, or extending Arion to build your own filter.