Topic starter
16/08/2026 4:59 pm
TL;DR: Kubernetes environments become hard to govern as workloads, namespaces, and ownership spread across teams, with visibility gaps making segmentation decisions risky and often deferred, according to Zero Networks. The practical issue is not that Kubernetes lacks controls, but that security teams cannot reliably see, validate, and sustain least-privilege communication paths as clusters change.
Editorial analysis by NHI Mgmt Group, based on content published by Zero Networks: “The Kubernetes Rubik’s Cube: Solving Visibility, Governance, and Segmentation at Scale”.
Key questions
Q: What breaks when Kubernetes segmentation is planned without workload visibility?
A: Teams end up choosing between two bad options: they block traffic and risk breaking applications, or they leave connectivity open and accept unnecessary exposure.
Q: Why does broad east-west access increase risk in Kubernetes clusters?
A: Broad east-west access lets a compromise in one pod reach internal APIs, databases, or management services that were never meant to be exposed.
Q: How do security teams know whether Kubernetes segmentation is working?
A: They should be able to compare intended policy with observed workload behaviour and see that unnecessary communication is being removed, not just documented.
Practitioner guidance
- Map live workload communication before enforcing segmentation Build a current view of namespace-to-namespace and service-to-service traffic so policy decisions reflect actual behaviour rather than stale diagrams.
- Review east-west reachability for every critical namespace Identify unrestricted paths, unexpected cross-namespace connections, and services that can reach databases or management components without a clear business need.
- Reconcile policy drift against active cluster behaviour Compare existing Network Policies to observed workload communication so temporary exceptions and inherited rules do not become permanent exposure.
Bottom line: Kubernetes segmentation fails when teams cannot prove which workload connections are still needed and which are just legacy exposure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
16/08/2026 5:00 pm
Visibility is now the real segmentation control: Kubernetes environments do not fail because segmentation concepts are missing, they fail because teams cannot reliably see what needs to talk to what. Once clusters, namespaces, and ownership spread across teams, policy decisions become dependent on partial knowledge. The practitioner lesson is to treat observability of workload communication as a governance control, not a convenience feature.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own decisions when Kubernetes communication needs change?
A: Ownership should sit with the teams that understand the application dependency, the platform constraints, and the risk posture together. Application teams know the service need, platform teams know the cluster mechanics, and security teams define the governance threshold. If those views are split, risky access often persists by default.
👉 Read our full editorial: Kubernetes visibility and segmentation at scale: the governance gap