Lesson 10 · Security, telemetry & operations
AuthorizationPolicy & edge auth
Deciding who may call what — the Istio way, and the way this repo actually does it.
Your win: explain AuthorizationPolicy and RequestAuthentication (the cert material), and contrast them with how this repo actually enforces access — in the app and at the edge, not in the mesh for backend services.
Authorization — the layer above identity
mTLS (Lesson 9) proves who is calling. AuthorizationPolicy decides whether that identity is allowed to do what it's asking — an ALLOW/DENY rule matching on the source (principal/namespace), the operation (paths, methods), and conditions.1 Two related resources:
| Resource | Answers |
|---|---|
| PeerAuthentication (L9) | must the peer use mTLS? (workload identity) |
| RequestAuthentication | is the end-user's JWT valid? (origin identity) |
| AuthorizationPolicy | given identity, is this call allowed? |
The zero-trust chain
Full mesh-level access control layers all three: mTLS proves the workload, a
RequestAuthentication validates the user's JWT, and an AuthorizationPolicy says "identity X may
POST /v1/foo." Each answers a different question. In an interview, being able to
place a given rule in the right layer is the tell that you understand the model.
How this repo enforces access — not via Istio (for backend)
Anchor — no backend AuthorizationPolicy
Consistent with mTLS being off (Lesson 9), backend services have no
AuthorizationPolicy and no RequestAuthentication (grep = 0).
Access control happens in the application: the service validates the caller's token
and maps it to gRPC metadata (the interceptor pattern from the gRPC course). The mesh routes
the request; the app authorizes it.
Anchor — two edge techniques the repo does use
Even without AuthorizationPolicy, the repo enforces boundaries:
- At the edge, via VirtualService
fault.abort: bob returns 403 to block Internal RPC paths from the public gateway (backend/bob/values.yaml:42-46, Lesson 4). A routing rule used as a coarse access control. - Istio authz IS used — but only for platform/monitoring: the one place
this repo reaches for
AuthorizationPolicy+ JWTRequestAuthenticationis guarding the monitoring/Grafana ingress (platforms/monitoring/<env>-gateway.yaml) and Atlantis (platforms/atlantis/authz.yaml) — infra dashboards, not business traffic.
In-app vs in-mesh authz — the trade-off
In-app authorization keeps business rules next to the business logic (fine-grained, testable
in Go), at the cost of each service re-implementing the check. Mesh authz is centralised and
language-agnostic but coarser (paths/methods, not "can this user edit this record").
Most teams end up with both: mesh for coarse identity/edge rules, app for fine-grained. This
repo leans fully on the app for backend — a reasonable, if not zero-trust, choice.
Backend use case
Backend use case: this helps explain why backend auth is mostly in-app here, with AuthorizationPolicy appearing mainly in platform and monitoring contexts.
Common mistake
Common mistake: assuming that because Istio supports authz, the backend services in this repo must be using mesh-native authz already.
Read this next
Istio docs — AuthorizationPolicy (+ authn policy task)
ALLOW/DENY rules, source/operation matching, and how it composes with mTLS and JWT authn.
→ istio.io — AuthorizationPolicy
→ istio.io — Authentication Policy (task)
In plain English
Plain English: AuthorizationPolicy is Istio’s way to decide which identities may call which routes, but that does not mean every mesh chooses to use it everywhere.
Check yourself (from memory)
Q1. AuthorizationPolicy decides…
Authz = access control (ALLOW/DENY by source/operation). mTLS
proves identity; authz decides what it's allowed.
Q2. A valid end-user JWT is checked by…
RequestAuthentication validates origin (end-user) JWTs; Peer
is workload mTLS. This repo uses ReqAuth only for monitoring.
Q3. Backend access control in this repo is done…
No backend AuthorizationPolicy; the app validates tokens. Only
platform/monitoring uses Istio authz + JWT.
The 3 security resources, and how this repo really does authz.
recall, then click to reveal
THREE LAYERS: PEERAUTHENTICATION (must the peer use mTLS? — workload
identity, L9); REQUESTAUTHENTICATION (is the end-user's JWT valid? — origin identity);
AUTHORIZATIONPOLICY (given identity, is this call ALLOWED? — ALLOW/DENY by source/operation).
mTLS proves WHO; authz decides ALLOWED. REPO: backend has NO AuthorizationPolicy/
RequestAuthentication — access control is IN-APP (validate token → gRPC metadata, the
interceptor pattern). Edge techniques it DOES use: VirtualService
fault.abort 403
to block Internal RPCs (bob/values.yaml:42-46); and Istio AuthorizationPolicy +
JWT ONLY for platform/monitoring (Grafana ingress, Atlantis). Trade-off: in-app = fine-grained
but repeated; mesh = centralised but coarse. This repo leans on the app for backend.
Want to see the monitoring gateway's JWT + AuthorizationPolicy, or how in-app gRPC auth
interceptors work? Ask me.