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:

ResourceAnswers
PeerAuthentication (L9)must the peer use mTLS? (workload identity)
RequestAuthenticationis the end-user's JWT valid? (origin identity)
AuthorizationPolicygiven 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:
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.
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)

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.

1. Istio — AuthorizationPolicy.