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.
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:
- Be named
payments-api-only-frontendin namespacepayments-mesh. - Select only workloads labelled
app=payments-api. - Use action
ALLOW. - Allow only the ServiceAccount
frontendin namespaceweb-mesh. - Allow only TCP port
8080.
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-apiRetrieval 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.