ICA: Securing Workloads

What this domain tests

Securing Workloads covers Istio identity, mutual TLS, request authentication, and authorization. You must know which resource enforces encryption, which one validates a JWT, and which one actually blocks a request.

Core rules

• Istio issues X.509 certificates with SPIFFE identity spiffe://cluster.local/ns/<namespace>/sa/<service-account>. Istiod rotates certificates; Envoy fetches them through SDS.
• PeerAuthentication modes are STRICT, PERMISSIVE, and DISABLE, scoped to mesh, namespace, or workload. portLevelMtls can make exceptions.
• RequestAuthentication validates a JWT when one is present, using issuer and jwksUri; it does not require a token.
• AuthorizationPolicy actions are ALLOW, DENY, and AUDIT. Rules use from for source principals or namespaces, to for paths and methods, and when for conditions. If ALLOW policies select a workload, unmatched traffic is denied; DENY is evaluated first.
• Require a validated JWT by matching requestPrincipals in an AuthorizationPolicy.

Worked example

Namespace api must accept only mTLS and require a JWT for /v1/*. Set PeerAuthentication to STRICT. Add RequestAuthentication with the issuer and JWKS URI. Add an ALLOW policy with requestPrincipals: ['https://issuer.example/*'] and paths /v1/*. Reasoning: RequestAuthentication alone lets tokenless requests through; the ALLOW policy creates default deny for selected pods. If the issuer string differs from the token, authorization fails even though the token is valid.

Traps

Leaving PERMISSIVE and assuming plaintext is blocked; treating authentication as authorization; using the wrong namespace or workload selector; enabling STRICT before clients migrate; and omitting the requestPrincipals condition so any authenticated or unauthenticated request passes.