Method-aware authorization with Istio policy
identity- and method-scoped authz.
an ALLOW policy on user-service granting frontend's principal POST plus the users path, another granting all principals GET; deny is implicit once any ALLOW exists.
What's really being asked
Whether you can combine workload identity from mTLS with HTTP method and path matching, and whether you understand Istio's allow-deny evaluation semantics.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
You add one Istio AuthorizationPolicy with action ALLOW permitting frontend to POST. A teammate worries other services can still POST. What actually happens to their POST requests?
- a.The policy is ignored because it matches by identity, not IP
- b.They are denied, since an applicable ALLOW policy makes unmatched requests deny-by-defaultCorrect
- c.They are allowed until you add an explicit DENY policy
- d.They are allowed because only DENY policies block traffic
Why? this is the answer
Once any ALLOW policy applies to a workload, requests not matching an ALLOW rule are denied by default, so other services' POSTs are blocked without an explicit DENY. Identity matching via mTLS is exactly the correct approach.
Just read this? Test yourself on what you have been reading.
Read the original → istio.io
- #istio
- #authorization
- #security
- #rbac
- #mtls
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles