Sidecars instead of Gateways
In the gateway demo,
APISIX calls a shared, centrally-deployed OPA for every authorization decision — one enforcement point,
one network hop, one blast radius if that OPA instance misbehaves. Here, each service gets its own
OPA instance sharing its network namespace (network_mode: service:<app> in
docker-compose) — reachable only at localhost:8181,
loaded with only that service's own policy. The gateway still authenticates the request (real JWKS
signature verification); it just never makes an authorization call itself.
- • One shared OPA, called by the gateway
- • Single enforcement point to secure and monitor
- • Policy changes affect every route through that gateway
- • A gateway bypass (internal network call) skips authz entirely
- • One OPA per service, loaded with only its own policy
- • No network hop — same host, same network namespace
- • A policy bug in one service can't affect another's sidecar
- • Authz still applies even if a caller reaches the service directly
- • More containers to run and keep patched (real cost, not free)
Same authentication as the gateway demo (Keycloak ROPC, JWT verified by APISIX'sopenid-connectplugin) — the difference is what happens next. On these routes APISIX does authentication only. There is no OPA plugin on /sidecar-demo/* at the gateway. Instead, demo-api itself calls an OPA instance running as its own co-located sidecar container (reachable only at localhost:8181 — a shared network namespace, not a shared network) for the authorization decision.
1. Authenticate
2. Call sidecar-enforced endpoints
Each button below hits a route where APISIX only checks the JWT signature —demo-apimakes the actual allow/deny call to its local OPA sidecar.
Request Log
No requests yet.
- What it costs
- One OPA container per service instead of one shared instance — more processes to run, monitor, and keep patched. Policy is co-located, so a broad change means redeploying every sidecar rather than editing one central policy.
- When you'd choose differently
- Reach for the gateway pattern when a single central enforcement point is easier to secure and reason about, or when the extra containers aren't worth it for your scale. The sidecar pattern earns its cost when blast-radius isolation and defence-in-depth (authz still applies even if a caller reaches the service directly) matter more than operational simplicity.