mTLS Is Not A Containment Policy

The connection is encrypted. Both workloads have valid certificates. The dashboard is green.

Now assume the calling workload is compromised. Which services can it still use?

That is the containment question. A successful handshake is not the answer.

Identity Is An Input To Policy

NIST SP 800-207A describes cloud-native access control using application and service identities alongside network parameters and user identities. Its architectural direction is granular application access, not simply encrypted connectivity.

Istio’s security documentation makes the separation concrete: peer authentication establishes service identity, while authorization determines permitted access. On Kubernetes, Istio uses service accounts as service identities.

My implementation takeaway: do not let membership in a trusted certificate domain become a substitute for deciding which caller needs which destination.

Consider a hypothetical reporting worker and a payment service. Both legitimately belong to the same mesh. The reporting worker needs to read a reporting API. It has no business submitting payment instructions.

If policy permits both operations, an authenticated connection from the reporting worker is not evidence that containment works. It is evidence that the worker can exercise the permission it was given.

Know What Your Authorization Default Actually Does

The Istio AuthorizationPolicy reference documents the evaluation order. Matching CUSTOM and DENY policies can reject a request. After those checks, if no ALLOW policy applies to the workload, authorization allows the request. If ALLOW policies exist, at least one must match.

That matters during rollout. Enabling peer authentication is not the same change as installing a narrow authorization baseline.

Review every policy that applies to the destination, including broader namespace or mesh-level rules. A precise-looking rule is not sufficient evidence if another applicable ALLOW rule also permits the caller.

For an initial implementation, I would write the intended access contract before writing configuration:

Caller	Destination	Intended permission
Reporting worker	Reporting API	Read approved reports
Reporting worker	Payment API	None
Checkout service	Payment API	Submit a payment request
Any application workload	Segmentation administration	None by default

This is a proposed design, not a product configuration or a claim about an observed intrusion. Translate it into controls supported by the actual deployment mode. Keep business-object authorization in the application where the enforcement point lacks that context.

An allowed payment endpoint must still decide which payment the caller may submit.

Keep A Network Boundary Beneath The Service Contract

Do not ask one policy layer to answer every question.

Use network microsegmentation to define reachable services. Use authenticated service identity and application-aware authorization to narrow permitted callers and operations. Use application controls for business permissions.

The Kubernetes NetworkPolicy documentation specifies an important operational constraint: policies need a networking implementation that enforces them. Creating the resource alone does not provide isolation.

It also documents additive policy behavior. Applicable allow rules combine, and both source egress and destination ingress must permit a connection when those directions are isolated. A broad allow policy is not cancelled by adding a more restrictive one.

For the hypothetical reporting worker, my proposed network baseline would allow its reporting dependency and explicitly reviewed supporting services. It would not grant general access to payment, administration, or unrelated application endpoints.

Inventory DNS, telemetry, certificate provisioning, and other actual dependencies before enforcement. Do not turn a temporary connectivity fix into a permanent namespace-wide exception. Check how the chosen mesh mode and network implementation interact before treating their policies as independent guarantees.

Test With A Valid Identity That Should Be Denied

A useful acceptance test needs more than an invalid certificate. That proves a different property.

For this design, I would require the following evidence in a representative test environment:

The reporting worker can complete its approved reporting operation.
Another valid workload identity cannot perform that operation without an explicit grant.
The reporting worker cannot call the payment service.
An approved caller cannot use an unapproved operation where operation-level enforcement is part of the design.
Direct addressing and alternate exposed ports do not provide an unintended route around the expected enforcement point.
Removing the worker’s access produces the intended result for both new requests and already-established sessions.

Record which layer rejected each attempt. A network rejection proves the path is closed; it does not prove that the service authorization policy is correct. Test that policy separately through an authorized test path.

Likewise, a service-level denial does not prove that unrelated network destinations are unreachable.

For existing connections, do not assume that updating network policy terminates them. Kubernetes explicitly leaves the effect of policy changes on existing connections to the network implementation. Define and test the session-termination procedure you actually need.

Protect The Authority Behind The Identity

The next review should cover who can assign the approved service account, change workload labels, modify authorization rules, and administer enforcement.

Treat those as part of the proposed containment boundary. If the test caller can simply acquire the approved identity or rewrite the rule, the original denial is not a useful end state.

For each permitted path, keep a named owner, a business reason, and a repeatable negative test. Review identity assignment and policy changes together rather than maintaining two unrelated approval trails.

The useful outcome is not “all traffic uses mTLS.” It is a documented answer to a harder question:

When one correctly authenticated workload becomes hostile, which destinations and operations remain unavailable to it?

Sources

Prepared with AI assistance.

microsegment.io