# Review Kubernetes NetworkPolicy as combined permissions at both endpoints

> One restrictive-looking policy does not cancel another policy’s allowed traffic.

- Canonical URL: https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:14:56+00:00
- Modified: 2026-10-20T18:34:32+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

One restrictive-looking policy does not cancel another policy’s allowed traffic.

## Potentially affected

Review the documented IP/port-level Kubernetes NetworkPolicy model and the plugin needed to enforce it.

## DSE recommendation

DSE recommends mapping a connection from its initiating Pod to its destination and reviewing every matching policy at both ends.

## Article

One restrictive-looking policy does not cancel another policy’s allowed traffic.

## Source facts

Kubernetes NetworkPolicies are additive: the allowed connections from all applicable ingress or egress policies combine. For a connection between isolated Pods, the source’s egress and destination’s ingress must both allow it. Enforcement requires a network plugin that supports NetworkPolicy. A policy object’s existence therefore is not independent proof that traffic restrictions are active.

Source: [Kubernetes documentation — Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/).

## Applicability

Review the documented IP/port-level Kubernetes NetworkPolicy model and the plugin needed to enforce it.

## DSE recommendation

DSE recommends mapping a connection from its initiating Pod to its destination and reviewing every matching policy at both ends. Record required DNS and external-service access alongside application ports. Treat a broad namespace or Pod selector as a real expansion of effective permission, even if a narrower policy remains present. Verify the installed network implementation before presenting a policy as an isolation control. Keep expected denied paths in the change record so testing does not stop after confirming the application can still communicate.

## Verification

In an approved test namespace, exercise one allowed flow and one explicitly unintended flow. Add a temporary policy that broadens the allow set and observe the combined result. Remove the test configuration and confirm that both ingress and egress behavior match the final design. Retain the complete matching policy set and both Pod label sets beside the test result. Have the network owner account for an unexpectedly allowed connection before considering a narrower-looking policy sufficient.

## Official reference

[Kubernetes documentation — Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/). Reviewed October 20, 2026.

## Primary reference

- Name: Kubernetes documentation — Network Policies
- Authority: kubernetes.io
- URL: https://kubernetes.io/docs/concepts/services-networking/network-policies/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Review Kubernetes NetworkPolicy as combined permissions at both endpoints,” DSE Security, https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.