Can the Packet Reach the Identity’s Target?

Thu, 22 Oct 2026 00:00:00 +1100

The access review says the workload identity can read the storage account. The network diagram says the subnet has no route to it.

Which one is right?

Possibly both. Azure RBAC describes authority. Routes, DNS, firewalls, and network security groups shape reachability. Until you test the same source, destination, protocol, and operation, those documents are describing different slices of the system.

There is a familiar temptation here: treat a “reachable” result as an attack path, or an “unreachable” result as containment. Both conclusions get ahead of the evidence.

The Mental Model

A network test answers a narrow question: from this source, can a particular kind of connection be established to this destination at this time?

It does not answer whether the workload has permission to perform an operation once connected. Nor does a role assignment answer whether the packets can get there.

The testable claim is not “the identity can reach storage.” It is more like: “This VM’s application process resolves this hostname to this address, can establish TCP 443, and can read this test object using this principal.”

That sentence is longer because the architecture is more complicated than one green check.

Reachability is a property of a tested source, destination, protocol, and time—not an enduring property of an identity.

How It Really Works

Fix the test tuple before you run a probe

Record the source resource and actual runtime context, target FQDN or IP, expected resolver, protocol, destination port, and the business operation to test. For a workload identity path, capture the principal ID and the exact data or service action separately.

Avoid a vague scan of “the subnet.” A VM and a container on that VM may have different local firewall, proxy, DNS, or identity behaviour. A subnet-level effective rule view can explain policy, but it cannot prove what a process used.

For this article’s example, assume an Azure VM application connects to an Azure Storage Blob private endpoint using the service hostname and HTTPS on TCP 443. It is illustrative; no test was run against an Azure subscription. Record actual VM/Storage SKUs, region, endpoint subresource, resolver configuration, and client SDK/API version before applying the method to a tenant.

Use diagnostics for the question they can answer

Azure Network Watcher’s Connection troubleshoot supports TCP or ICMP tests from documented sources including virtual machines and virtual machine scale sets to destinations including VMs, FQDNs, URIs, and IP addresses. Its results can surface connectivity, DNS, route, NSG, and other supported configuration issues. The agentless experience is currently documented as preview; feature availability and behaviour need to be checked for the target environment.

That is useful. It is not an application transaction. A TCP success says a connection probe reached a listening port under the tested conditions. It does not prove the application resolved the same name, used the same proxy, negotiated TLS as expected, or presented the identity you reviewed. A TCP failure can come from the target not listening, a guest firewall, a missing route, policy, or a diagnostic prerequisite—not necessarily the security boundary you meant to test.

Pair the diagnostic with a test from the actual workload context. Resolve the application hostname there, record the address, then attempt a safe connection. Where practical, make a non-mutating application request with the intended identity. Keep results separate so one tool’s scope is not mistaken for another’s.

Inspect policy, but don’t confuse it with observation

Review the effective route, relevant NSG rules, Azure Firewall or network virtual appliance policy, peering/gateway path, and target-side restrictions that apply to the source/destination tuple. Which surfaces matter depends on the topology. A route table screenshot without the effective next hop is not enough; an NSG allow rule does not prove the target is listening.

For Network Watcher, confirm the service is enabled in the source VM’s region and check its current RBAC permission requirements. Built-in Network Contributor, Contributor, and Owner roles can include broad actions; custom roles may be more appropriate after verifying the exact diagnostic actions. Do not expand permissions merely to make a one-time test convenient.

The diagnostic data model, API version, supported sources, and permission set can change. This draft does not call a Network Watcher REST API, query a log schema, or assume a specific VM agent/extension. Name those versions and prerequisites when a real implementation uses them.

Test the service operation separately

If TCP connects, use the workload’s credential path to attempt one safe, read-only operation. For Blob Storage with Microsoft Entra ID, the data service evaluates authorization for the request; network reachability does not make the request permitted.

If the operation fails, record the service response and identity used. If it succeeds, record the object and operation. Avoid logging bearer tokens. The test should use non-sensitive data and a principal with only the access required for that test.

Real-World Impact

Suppose a workload has a role that appears to permit access to a sensitive data store, but the test from its current source cannot reach the target. That is worth investigating, but it is not a reason to leave the role untouched forever. The route may change; a proxy or alternate path may exist; another workload may share the identity.

Now reverse the result. The TCP probe succeeds, but the data operation is denied. Adding more network blocks might not reduce the specific authority exposure at all. The intended identity may not be in use, or the permission may be missing. An error message and principal ID are more useful than another blanket rule.

Use a reachability matrix that records both positive and negative cases:

Source	Destination	Protocol/port	Network result	Service operation	Interpretation
Workload process	Intended endpoint	TCP 443	Observed result	Safe read as target identity	Tests intended path
Same source	Known out-of-scope endpoint	TCP 443	Observed result	No data operation	Challenges network boundary
Same source	Intended service name	TCP 443	Observed result	Same read with wrong/unauthorized identity, if safe	Separates reachability from authority

Fill this in only from real tests. A blank or untested cell is not “denied.” Re-test after the change and retain the exact source, destination, protocol, timestamp, and identity so another engineer can reproduce the claim.

Gotchas and Edge Cases

The gap between control-plane configuration and a running process is where confident conclusions tend to get expensive. A clean route analysis can coexist with an application outage; a successful probe can coexist with a broken trust boundary.

Diagnostic sources may not match the process

Connection troubleshoot operates from supported Azure resource types and test modes. A test from a VM does not automatically represent every container, sidecar, proxy, or application library on that VM. Record what emitted the traffic and what did not.

A port test can pass for the wrong service

An address can accept TCP without being the intended service. Check DNS, destination ownership, TLS/service identity, and the application response. Do not treat “socket opened” as equivalent to “request reached the intended resource.”

Network policy is not the only failure domain

Guest firewall, process configuration, server listener state, DNS, service firewall, and platform diagnostic prerequisites may all affect results. Classify the failure before proposing a security change. If the diagnostic itself needs permissions or connectivity the workload lacks, that is not proof the workload’s normal path is blocked.

One successful test ages quickly

Routes, DNS, identities, and policy change independently. A reachability result is a snapshot, not a perpetual guarantee. Preserve its time and configuration context, and decide which changes invalidate it.

Best Practices

Before changing policy, write down what a passing test means. Specify the workload context, FQDN and expected destination, TCP/ICMP choice, port, identity, operation, and what result should be denied. Then use a diagnostic that answers the network question and a separate request that answers the authorization question.

When results disagree, don’t average them. If the network probe succeeds and the service denies access, inspect identity and operation. If the role appears valid and the request times out, inspect DNS, routing, enforcement, and target listener. If the answers change depending on source, name that boundary instead of calling the environment “reachable.”

Finally, preserve the failed and successful cases. They define where the boundary currently is. After a remediation, run the same tuple again and test an adjacent path that should remain available. That is how you tell containment from accidental outage.

🍺

Brewed Insight: The packet can reach a target the identity cannot use. The identity can be authorized for a target the workload cannot reach. Neither edge is the whole path; the review has to test where they meet.

Network Watcher on Brewed in the Cloud by Chris Hailes