Supplemental Lesson 0026 · 25 minutes · Istio service-mesh security

Allow one workload identity to call the payments API

Strict mTLS proves the client has a mesh identity. An Istio AuthorizationPolicy decides which authenticated identity may actually call a workload. Together, they turn encrypted traffic into least-privilege service access.

Security reflex: use a SPIFFE-style principal when access must be tied to one ServiceAccount. A Namespace name alone is broader: every workload in that Namespace could match it.

Timed task: 15 minutes

Read lab/lesson-26-fixture.yaml. Assume Lesson 25 strict mTLS is already active in payments-mesh. Create lab/lesson-26-answer.yaml from scratch with one Istio AuthorizationPolicy.

The policy must:

Do not allow an entire Namespace, use a wildcard principal, add an HTTP method/path rule, or create a PeerAuthentication policy. The local Kind cluster does not have Istio, so this is a manifest-reading exercise.

Identity shape

cluster.local/ns/<namespace>/sa/<serviceaccount>

Istio obtains that identity from mTLS. This is why strict mTLS is the foundation for this type of workload authorization.

Verification on an Istio cluster

kubectl apply -f .\lab\lesson-26-fixture.yaml
kubectl apply -f .\lab\lesson-25-answer.yaml
kubectl apply -f .\lab\lesson-26-answer.yaml
kubectl -n payments-mesh get authorizationpolicy payments-api-only-frontend -o yaml
istioctl x describe pod -n payments-mesh -l app=payments-api

Retrieval check

Question

Why is the source principal safer here than allowing all clients from web-mesh?

Documentation target

Use Istio’s official AuthorizationPolicy reference and security concepts.

What to send me

Paste the single policy YAML. I’ll review it one issue at a time and will not reveal the next correction early.