Supplemental Lesson 0025 · 20 minutes · Istio service-mesh security

Require mTLS for one application namespace

Istio sidecars can automatically use mTLS, but permissive acceptance may still allow plaintext requests. PeerAuthentication with STRICT tells receiving workloads to accept only mTLS traffic.

Security reflex: PeerAuthentication controls what the destination workload accepts. For namespace-wide policy, use no workload selector; a selector narrows the policy to only matching Pods.

Timed task: 12 minutes

Read lab/lesson-25-fixture.yaml. Create lab/lesson-25-answer.yaml from scratch with one Istio PeerAuthentication resource.

The policy must:

Use API version security.istio.io/v1.
Be named default in namespace payments-mesh.
Require STRICT mTLS for every workload in that namespace.
Contain no workload selector and no port exceptions.

The local Kind cluster does not have Istio installed, so do not apply this manifest there. This is API and policy-scope practice; on an Istio cluster, first apply the supplied fixture so the Namespace receives sidecar injection.

Verification on an Istio cluster

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

The first command creates the injection-enabled namespace and workload. The final command confirms the workload is in the mesh and helps diagnose mTLS policy state.

Retrieval check

Question

Why should this namespace-wide policy omit spec.selector?

Without a selector, it applies to every workload in its own namespace.Selectors disable automatic certificates.A selector would make the policy cluster-wide.

Documentation target

Use Istio’s official PeerAuthentication reference and mTLS authentication task.

What to send me

Paste the single policy YAML. I’ll check it one issue at a time and won’t reveal the next correction early.