Kubernetes NetworkPolicy: Follow Both Ends of a Connection

Start with the source and the destination

A platform offer says that inference clients are separated from one another and that only selected clients can reach an inference Pod. To assess that statement, identify a particular source Pod, destination Pod, protocol and destination port. An ingress explanation at the inference Pod addresses only one end of that connection.

The archived Kubernetes v1.34 Network Policies guide distinguishes ingress isolation from egress isolation. A Pod can be isolated in either direction independently. With a conformant supporting network implementation, a new Pod-to-Pod connection needs the source's egress and destination's ingress to permit it. Creating policy objects without an implementation that enforces them supplies no such control.

Use that versioned scope when reading the example below. It concerns ordinary Pod traffic after the stated policies have been handled. Node traffic, self-connections, hostNetwork Pods, service-address translation and other policy systems are outside its premises.

References: [K1]

Selection identifies whose traffic a policy describes

A NetworkPolicy selects the Pods to which its declared direction applies. A policy selecting a destination for ingress restricts traffic entering those selected Pods; its peer rules describe permitted sources. An egress policy instead describes permitted traffic leaving its selected Pods. Selection of the subject and selection of an allowed peer perform different jobs.

The version-pinned Kubernetes API v0.34.0 definitions also require the peer and port conditions of a rule to match together. Finding the desired peer in one unrelated allowance and the desired port elsewhere does not establish that pair. Keep the connection's protocol and destination port attached to each match.

The example supplies those selector and rule matches explicitly. It asks what the resulting allowances mean, without prescribing labels, manifests or changes to a cluster.

References: [K2]

NP-74: combine three policies at one inference Pod

Consider fictional clients A, B and C, each a separate ordinary Pod, and inference Pod D. The only candidate connections in this example are new TCP connections from each client to D's destination port 8443. The port and all identities are invented teaching inputs, not a recommended service interface or an observed cluster.

Three policies select D for ingress. P-A permits A to D on TCP 8443. P-B permits B to D on TCP 8443. P-0 declares the ingress direction but has zero ingress rules. Assume these are all the ingress policies applicable to D and that their selector matches have already been resolved.

P-A contributes the A connection; P-B contributes the B connection; P-0 contributes no connections. Combining their contributions leaves A and B permitted at D's ingress. C has no matching ingress allowance in this supplied set. P-0 supplies no instruction to cancel P-A or P-B.

Zero ingress rules is important here. P-0 is not a rule with unrestricted peer or port conditions. Its contribution is empty, while the other contributions remain present. The interpretation follows the combined set, rather than treating the last policy in a document list as the final verdict.

References: [K2]

Complete the decision at each client's egress

Now supply the other half of NP-74. Each of A, B and C is also isolated for egress. A's applicable egress allowances permit D on TCP 8443, and B's do too. C has no matching egress allowance for that connection. Assume the described sets are complete for these clients and that the conformant implementation has handled them.

A to D meets both directional conditions: A permits the outbound connection and D permits the inbound connection from A. B to D meets both for the same reason. C to D meets neither in this case. Thus two of the three candidate new connections are allowed by the stipulated NetworkPolicy state. This is a calculation from the supplied policy relationships, with no attempted connection or inference result.

The two columns cannot substitute for one another. In a separate hypothetical state where B lacks its egress allowance but D still permits B, the B connection fails the two-end test. Conversely, giving C an egress allowance alone would leave D's missing ingress allowance for C unresolved. Neither illustration is a direction to change a real policy.

References: [K1][K2]

Another empty contribution leaves these grants intact

Suppose a supplier adds a fourth policy selecting D for ingress and contributing zero ingress rules, while every other NP-74 premise stays the same. The ingress set still contains the A and B connections. Three applicable ingress policies have become four, but neither existing grant has been removed.

Reordering P-A, P-B and P-0 also leaves the result unchanged. A before B, B before A, or the empty contribution between them all supply the same two connections. This is why counting objects or showing an empty policy in isolation cannot substantiate a claim that B has been excluded.

This does not mean creating any NetworkPolicy can only broaden traffic. If an ordinary Pod was previously non-isolated in a direction, selecting it for that direction can establish isolation. An otherwise sole ingress policy with no allowances has a different surrounding state from P-0 alongside P-A and P-B. In NP-74, D is already isolated and the two other policies continue to grant A and B. The initial state and all applicable policies are essential to the conclusion.

References: [K1][K2]

Compare the described connection set with the buying requirement

If the buyer requires A and B to be network-eligible clients of D while C is excluded, NP-74 describes that result for the three new TCP 8443 connections. If the requirement instead permits A alone, the same state leaves B allowed. Calling the fourth empty contribution an extra restriction does not reconcile that difference.

Have the platform provider explain the effective source and destination allowances for the actual required connections, including which Pods each policy selects and which rules match the complete peer/protocol/port combination. If only the destination policies are supplied, the source-egress conclusion remains open. If only one selected policy is supplied, other applicable grants remain to be accounted for.

Keep the result attached to its actual implementation and observation boundary. The v1.34 guide explains that policy handling can take time and that the API does not reveal exactly when a network plugin has handled an object. It also leaves the effect of policy-set changes on already established connections to the implementation. A proposed new-connection restriction therefore cannot establish an instant cutoff of a session already in progress.

For the requirement being purchased, distinguish the described policy result, evidence of its effective implementation, and the application outcome. NP-74 supplies only the first under explicit assumptions.

References: [K1]

Carry the connection result into the application question

An allowed A-to-D network connection does not say which model A may invoke or which data it may read. It also does not show that D is listening, that a request reached it, or that inference completed. Those conclusions need their own applicable evidence from the responsible application and platform owners.

The related resource-authorization article follows decisions through enforcement for a particular resource and action. The Kubernetes RBAC article instead follows permissions to make API requests through role definitions and bindings. NetworkPolicy answers the connection question in this article; neither an API grant nor an application identity replaces that calculation.

For a separately selected equipment or physical-link addition, Leviathan's Structured Cabling & Fiber Installation service provides the route to discuss customer-furnished or separately sourced cabling, approved routes, endpoint labels and physical records. Use the service and project inquiry with the actual equipment, endpoint schedule, material responsibilities and required handoff. NetworkPolicy design, software configuration and security acceptance remain with the appointed platform and security teams.

References: [L1]