{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/", "item": { "id": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/", "slug": "review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints", "url": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints.md", "json": "https://update.dsesecurity.com/api/v1/posts/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/" }, "title": "Review Kubernetes NetworkPolicy as combined permissions at both endpoints", "summary": "One restrictive-looking policy does not cancel another policy’s allowed traffic.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:14:56+00:00", "modified_at": "2026-10-20T18:34:32+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 259, "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.", "primary_source": { "name": "Kubernetes documentation — Network Policies", "url": "https://kubernetes.io/docs/concepts/services-networking/network-policies/", "published_on": null, "authority": "kubernetes.io" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

Source facts

\n

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.

\n

Source: Kubernetes documentation — Network Policies.

\n

Applicability

\n

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

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official reference

\n

Kubernetes documentation — Network Policies. Reviewed October 20, 2026.

", "content_text": "One restrictive-looking policy does not cancel another policy’s allowed traffic.\nSource facts\nKubernetes 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.\nSource: Kubernetes documentation — Network Policies.\nApplicability\nReview the documented IP/port-level Kubernetes NetworkPolicy model and the plugin needed to enforce it.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nKubernetes documentation — Network Policies. Reviewed October 20, 2026.", "content_markdown": "One restrictive-looking policy does not cancel another policy’s allowed traffic.\n\n## Source facts\n\nKubernetes 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.\n\nSource: [Kubernetes documentation — Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/).\n\n## Applicability\n\nReview the documented IP/port-level Kubernetes NetworkPolicy model and the plugin needed to enforce it.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nIn 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.\n\n## Official reference\n\n[Kubernetes documentation — Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/", "url": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Review Kubernetes NetworkPolicy as combined permissions at both endpoints", "item": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/#article", "identifier": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/", "url": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/", "headline": "Review Kubernetes NetworkPolicy as combined permissions at both endpoints", "description": "One restrictive-looking policy does not cancel another policy’s allowed traffic.", "abstract": "One restrictive-looking policy does not cancel another policy’s allowed traffic.", "articleBody": "One restrictive-looking policy does not cancel another policy’s allowed traffic.\nSource facts\nKubernetes 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.\nSource: Kubernetes documentation — Network Policies.\nApplicability\nReview the documented IP/port-level Kubernetes NetworkPolicy model and the plugin needed to enforce it.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nKubernetes documentation — Network Policies. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:14:56+00:00", "dateModified": "2026-10-20T18:34:32+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/review-kubernetes-networkpolicy-as-combined-permissions-at-both-endpoints/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Review Kubernetes NetworkPolicy as combined permissions at both endpoints" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 259, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes documentation — Network Policies", "url": "https://kubernetes.io/docs/concepts/services-networking/network-policies/" } } ] } }