Does Docker Desktop provide a supported read-only way to verify SandboxKey and main-process network namespace identity?

[J3RS3Y99]

I would like to confirm whether Docker Desktop provides a documented, supported, read-only interface to establish that a container’s NetworkSettings.SandboxKey and /proc/<current-main-PID>/ns/net refer to the same network namespace object inside the Docker Desktop Linux VM.

This is a capability question, not a confirmed bug or network-isolation failure report.

Environment

• Currently installed Docker Desktop application metadata: 4.95.0, build 242831. This does not establish the version running during the historical observations below.
• Retained client-side host information: Darwin 25.6.0, arm64. This is a Darwin release string, not a macOS marketing-version claim.
• Historical probe target: linux/amd64.
• Historical Engine/API/CLI versions, Linux VM kernel, virtualization backend, Rosetta and Enhanced Container Isolation settings: not established by the retained evidence.

No new daemon queries have been performed to fill these gaps.

Two separate historical observations

A. Probe container

The prepared invocation specified --network none, user 1000:1000, a read-only root filesystem, all capabilities dropped, and no-new-privileges.

Retained execution records show successful creation and pre-start inspection. However, the available inspection records retain output hashes and lengths rather than complete inspect bodies, so they do not independently expose every actual HostConfig setting.

The probe reported:

• 10 valid, unique interface rows: one loopback and nine non-loopback;
• no malformed or duplicate rows;
• identical content hashes for /proc/net/dev, /proc/self/net/dev and /proc/thread-self/net/dev;
• matching, stable hashes of the sampled namespace-link strings.

These observations do not establish external connectivity, the origin of the proc view, or a virtualization/translation defect.

B. Separate controlled bridge-network container

A single read-only inspect → top → inspect observation recorded:

• the Engine-reported main PID appearing once in the process list;
• six processes sharing the same reported NETNS value;
• identical selected before/after inspection fields, including full container identity, image, main PID, start time, restart count, SandboxID and SandboxKey.

This was a historical association, not an atomic snapshot. Container B is not the failed probe container and uses bridge networking. Its result cannot establish the namespace or isolation of container A.

Missing evidence and questions

We have not obtained contemporaneous object identity for both paths in the daemon’s Linux VM—for example, device/inode identity and network-namespace type, with protection against PID reuse or namespace replacement.

1. Is there a supported Engine or Docker Desktop interface that provides this association without entering a debug shell or creating a privileged container?
2. If so, what versions, permissions, namespace/mount context and consistency limitations apply?
3. Is there a documented equivalent to comparing namespace file-object identity?
4. If no supported interface exists, could you confirm that limitation and identify the minimum supported alternative and its privilege requirements?

Please also identify which missing version/backend fields are essential before requesting further evidence.

Our current review boundary excludes privilege escalation, container execution or lifecycle changes, permission/configuration changes, probe reruns, image pulls/builds, and database or production access. Any suggested operational procedure would require separate review.

No credentials, application data, full container identifiers, local account paths or diagnostic bundle are included.