Securing Workloads
What this domain tests
Securing Workloads tests identity, mutual TLS, request authentication, and authorization. You need to know how PeerAuthentication, AuthorizationPolicy, and RequestAuthentication interact, and how SPIFFE identities appear in policy.
Core rules
- PeerAuthentication controls server-side mTLS. Modes are STRICT, PERMISSIVE, and DISABLE. A mesh-wide policy goes in the root namespace, normally
istio-system; a workload selector narrows it. - Istio issues SPIFFE identities such as
spiffe://cluster.local/ns/default/sa/frontend. AuthorizationPolicy matchessource.principals, namespaces, methods, paths, and JWT claims. - AuthorizationPolicy actions include ALLOW and DENY. DENY is evaluated before ALLOW. If a workload has any ALLOW policy, requests that match none are denied.
- RequestAuthentication validates JWTs; a JWT rule in AuthorizationPolicy only works when a RequestAuthentication is present for the same workload.
Worked example
Enable STRICT mTLS mesh-wide with a PeerAuthentication in istio-system and mode STRICT. In namespace backend, create an AuthorizationPolicy with action ALLOW and a rule from source principal cluster.local/ns/default/sa/frontend. Reasoning: STRICT rejects plaintext, so callers must use mTLS. The ALLOW policy creates default-deny for selected backend workloads, permitting only the frontend service account. A DENY policy would override this ALLOW.
Traps
- PERMISSIVE still accepts plaintext, so it does not enforce mTLS.
- An AuthorizationPolicy without a selector applies to all workloads in its namespace.
- A JWT claim match without RequestAuthentication is not validated and can silently allow requests.
- DestinationRule TLS settings can conflict with PeerAuthentication; check both sides when debugging.
- SPIFFE principals use trust domain and service account, not pod name or IP.