The direct answer
Review every applicable policy before deciding whether a worker’s intended Pod-to-Pod path matches the network plan. A narrow new policy does not subtract permissions granted elsewhere, and splitting a peer expression can widen the selected population. Keep network-plan eligibility separate from an observed connection, gateway enforcement and current application rights.
Ask whether the intended change actually narrows the path
An AI preprocessing worker should contact one internal gateway, not a neighboring workload. An operator adds a policy named “gateway only” and assumes the old broad route disappeared. Reviewing that object alone cannot answer whether the complete policy set still permits the neighbor.
The gateway coverage guide asks which calls traverse enforcement. This worksheet supplies a narrower infrastructure review decision: classify one direct Pod-to-Pod TCP path against a complete symbolic policy inventory. It is not a claim that every request reaches a gateway.
The official guide requires a supporting network implementation; a resource alone establishes no enforcement. Navigation shows v1.37; the displayed modification date is 14 April 2026. Actual cluster support remains unknown.
Evaluate directions and the complete allowed set
The guide makes isolation directional: a selecting policy must apply to that direction; otherwise it is non-isolated. Applicable allowances form a union. Source egress and destination ingress must both permit the path, including matching peer and port.
Invent source W-A in namespace N-W, gateway G-A in namespace N-G and fixed TCP destination port P-A. They are worksheet labels, not real addresses, namespace names or a configured port. Select ordinary non-host-network Pods and a direct path in one supported cluster. Exclude Services, address rewriting, host traffic, IP blocks, meshes and port ranges.
For each direction, record which policies actually select the endpoint, why each applies and which candidate paths its rules admit. Reviewers should be able to trace a conclusion to the complete set rather than a convenient recent change. An unknown policy, label state or enforcement path prevents this exercise from establishing actual coverage.
In the invented baseline, E-NARROW admits the intended G-A/P-A path, while E-BROAD also admits neighboring X-A. Keeping both does not meet the application’s gateway-only objective. Do not mark the change successful merely because E-NARROW looks correct. Any real removal or redesign requires its own authorized review; this article performs none.
Preserve the peer expression instead of its visual appearance
One peer combining namespaceSelector and podSelector matches Pods inside selected namespaces. Separate peers mean namespace-wide matches OR matching Pods local to the policy’s namespace.
For the proposed egress review, the intended destination means “gateway-class Pods inside the admitted gateway namespace class.” The corresponding ingress review means “worker-class Pods inside the admitted worker namespace class.” Both conditions matter. Keep the expression grouped as one peer condition on each relevant side.
A formatting refactor that separates the selectors changes the population under review. Ask the reviewer to enumerate the newly eligible classes before accepting it. Another namespace carrying a familiar Pod label, or an unrelated Pod inside a selected namespace, must not be waved through because one label resembles the intended peer.
These labels are routing classifications owned through separately trusted configuration. They do not authenticate a person, establish a tenant’s document rights or prove the gateway application is the reviewed program. Keep the application authorization boundary intact even when the peer sheet matches.
Keep a useful ordinary path ledger
Propose record R-A containing the source and destination associations, trusted label inventory, effective policy revisions, direction applicability, peer grouping, fixed protocol/port and supporting implementation evidence. Include a separate field for current job and payload authority. None of that actual evidence has been collected here.
| Question | Required worksheet evidence |
|---|---|
| What is the intended path? | Owned W-A to owned G-A on P-A, direct TCP only. |
| Which source rules matter? | Complete applicable source inventory, including any broader allowance. |
| Which destination rules matter? | Complete applicable destination inventory, separately classified. |
| Who matches each peer? | Explicit grouped namespace-and-Pod population, not an indentation impression. |
| What remains independent? | Supported enforcement, actual endpoint association, authorized payload and current application rights. |
The ordinary positive is a small authorized draft request whose complete hypothetical record matches the intended path and contains no conflicting application-scope expansion. It is conditionally eligible only as a network-policy plan. Actual plugin enforcement, policy inventory, labels, topology, identity and rights are unimplemented or unknown; their absence blocks real admission.
Walk eight inert composition cards
All cards are PROPOSED_UNRUN. No policy resource, packet or connectivity observation was produced.
| Card | Condition | Proposed disposition |
|---|---|---|
| 1. Ordinary path | Complete supported R-A matches W-A/G-A/P-A and independent rights. | Conditionally admit this narrow plan, not a successful request. |
| 2. Broad neighbor | E-BROAD remains beside E-NARROW. | Reject the claimed narrowing; reconcile the expanded population. |
| 3. One side missing | Source review matches but destination review denies or is unknown. | Do not approve the complete path. |
| 4. Grouped peer | Both intended selector conditions occupy one peer entry. | Retain the intended joint population for review. |
| 5. Split peer | A refactor separates those conditions. | Review changed alternatives; not a cosmetic edit. |
| 6. Unselected direction | The direction lacks an applicable isolating policy. | No restriction evidence from a policy elsewhere. |
| 7. Missing implementation | Support, labels, inventory or direct-path applicability drifts. | Hold coverage; saved configuration is insufficient. |
| 8. Application denial | Network plan matches but payload or current job rights fail. | Deny independently; no network-policy override. |
Stop the claim at the reviewed network boundary
This sheet supplies no encrypted transport, endpoint authentication, universal gateway routing, complete egress control or immediate termination of existing connections. It establishes neither an HTTP path/payload rule nor successful gateway processing. Probe readiness and job completion remain separate observations.
No cluster, API, CLI, manifest, Pod, namespace, label, network plugin, socket, packet, runtime fixture or model operation was inspected or exercised. Only documentation and editorial work occurred. Boundary remains prelaunch with planned request-path checks; its mock policy evidence does not implement or validate Kubernetes network enforcement.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.