Istio and NetworkPolicy enforce different communication boundaries

A policy's enforcement location matters when the workload it governs misbehaves. Istio's Envoy sidecar shares a Pod network namespace with the application. A typical Kubernetes NetworkPolicy implementation enforces outside that namespace, at the host node. Spike Curtis's August 10 comparison uses that distinction to explain why an Istio-enabled application can still benefit from network policy.

The article concerns Istio 0.1 and distinguishes service-aware policy from network and transport controls. Envoy can use HTTP attributes when making decisions about protocols it understands. NetworkPolicy can describe connectivity without interpreting the application's HTTP messages. The two mechanisms therefore have useful differences in both context and placement.

I support attaching policy to workload identity, but identity-aware service communication does not remove every network boundary. A service mesh still has infrastructure and neighboring workloads around it. Independent enforcement outside an application's own network namespace can restrict which of those destinations or entry points the application can reach.

The proxy sees application protocol details

The guide describes Envoy as a userspace daemon that uses ordinary sockets. At the service layer, it can examine a virtual host, URL or HTTP header. The article names HTTP/1.1 and HTTP/2, including gRPC over HTTP/2, as protocols relevant to this policy discussion.

NetworkPolicy operates at the network and transport layers. It can express rules for traffic without needing a corresponding application-protocol parser. Both mechanisms can use Kubernetes labels to identify Pod endpoints, so the distinction is not simply labels versus addresses. Their different access to protocol context determines which decisions each can express.

The guide qualifies its implementation comparison as typical behavior, with Calico as an example. It does not establish that every network provider has the same internal design. The broader point is that the network control can reside outside the guest Pod while Envoy's sidecar resides inside it.

Pod privileges affect the enforcement boundary

Some containers have CAP_NET_ADMIN, which allows them to reconfigure networking in their Pod. The guide explains that a compromised or malicious instance with that capability can bypass its local proxy. Correctly configured destination Pods can still retain their own Istio protection, but other traffic paths become relevant.

The article identifies unprotected Pods and cluster infrastructure among the possible targets. It also includes services outside the mesh, such as databases or legacy systems. A service's membership in the mesh therefore does not make every surrounding destination equally protected.

Node-level network enforcement requires a different escape to bypass it. The guide says a compromised Pod would have to break into the root namespace to evade that boundary. This is the concrete reason for combining the controls, independent of the proxy's richer request policy.

The ingress example restricts exposed ports

Istio's ingress Service exposes ports 80 and 443. The guide adds a NetworkPolicy selecting ingress Pods and allowing only those incoming ports. It uses this example to protect against accidental exposure of Envoy's administrative interface through a misconfigured image.

A correctly configured image should not expose that interface in the first place. The network rule adds an independently enforced restriction on incoming connections. This is a specific configuration error that another control can contain, rather than a claim that network policy substitutes for configuring Envoy correctly.

The guide's second example restricts the productpage service to calls from ingress Pods. Its manifest is concrete enough to show both the selected destination and the permitted source.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: product-page-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: productpage
  ingress:
    - ports:
        - protocol: TCP
          port: 9080
      from:
        - podSelector:
            matchLabels:
              istio: ingress

The Kubernetes 1.7 API definition requires a rule to match both its port and source constraints. Here, the destination Pods have app: productpage, and permitted source Pods in the same namespace carry istio: ingress. The allowed connection uses TCP port 9080.

The application graph becomes a connectivity input

Bookinfo's intended call graph gives the rules their purpose. The guide argues that ingress should not call the ratings service directly because that is not an intended application connection. Similar rules for each service can constrain the connectivity available even after one mesh member is compromised.

These permissions are additive under the 1.7 API. Other policies selecting the same destination can allow additional incoming traffic. The example's effective restriction therefore depends on the rest of the applicable policy set, together with a network plugin that enforces NetworkPolicy.

Selector scope also matters. An empty destination Pod selector would apply the policy to every Pod in its namespace, whereas the example deliberately confines that selection to the productpage application label.

The August article describes outbound policy as expected in Kubernetes 1.8, so it is not part of these current examples. My interest in the present demonstration is its separation of responsibility. Istio supplies service-aware behavior inside the Pod, while the network implementation can restrict connections at a boundary outside it. The Bookinfo rules express that second responsibility through the application's intended callers and ports.