Method-aware authorization with Istio policy

WHAT THIS TESTS Whether you can combine workload identity from mTLS with HTTP method and path matching, and whether you understand Istio's allow-deny evaluation semantics.

A GOOD ANSWER COVERS You apply AuthorizationPolicy resources in the user-service namespace with a selector targeting the user-service workload. The first rule is action ALLOW: source principals set to the frontend's identity, expressed as the SPIFFE principal or service account, with an operation specifying methods POST and paths /api/v1/users. The second rule is action ALLOW: any authenticated source, with operation methods GET. Istio evaluates DENY policies first, then ALLOW; critically, once at least one ALLOW policy applies to a workload, requests that match no ALLOW rule are denied by default. So these two ALLOW rules together permit frontend to POST to the users endpoint and everyone authenticated to GET, while frontend-less POSTs and any other method fall through to an implicit deny. This relies on strict mTLS so source principals are trustworthy.

COMMON WRONG ANSWERS Matching on source IP or namespace label instead of the mTLS principal; IPs are reassigned and spoofable. Forgetting that an ALLOW policy makes everything else deny-by-default, then adding a redundant explicit deny that conflicts. Putting the policy in the wrong namespace or selector so it does not bind to user-service. Allowing the method without scoping the path, accidentally exposing other POST endpoints.

LIKELY FOLLOW-UPS How is the principal derived and why does it require mTLS? What is the precedence between DENY and ALLOW and CUSTOM actions? How do you test a policy safely, perhaps with a dry-run or audit mode? How would you allow a path prefix versus an exact path?

ONE CONCRETE EXAMPLE Policy one selects app user-service, action ALLOW, from principals shop/sa/frontend, to operation methods POST paths /api/v1/users. Policy two selects the same workload, action ALLOW, from any principal under the mesh, to operation methods GET. A call from the orders service doing POST /api/v1/users matches no ALLOW and is rejected with 403, while its GET succeeds, and frontend's POST succeeds.