Netizen Blog and News

Kubernetes is built to make communication between workloads simple. Pods receive routable IP addresses, Services provide stable endpoints, and internal DNS allows applications to locate one another without tracking where each container is running. Those features make distributed systems easier to operate, but they can also produce a broad internal attack surface when network controls are missing or incorrectly configured.

A vulnerability in one container should remain confined to that workload. In many clusters, it does not. Once an attacker gains command execution inside a Pod, that Pod can become a foothold for scanning internal services, collecting credentials, querying the Kubernetes API, reaching node interfaces, and compromising workloads in other namespaces.

The result is a lateral-movement problem created through normal Kubernetes behavior rather than an exotic platform exploit.

The Kubernetes Network Is Often More Open Than Teams Expect

Kubernetes does not isolate Pod traffic by default. A Pod can normally send traffic to other Pods, Services, node addresses, and external systems when the cluster network permits it. Namespaces organize resources and create scopes for access controls, but they do not act as firewalls.

This distinction is easy to miss. A production database may run in one namespace, an internet-facing API in another, and a development workload in a third. The separation looks meaningful from an administrative perspective, yet the workloads may still communicate freely across the cluster network.

An attacker who compromises the public-facing API may be able to connect directly to the production database, cache server, metrics endpoint, message broker, or internal administration interface. The attacker may not need additional Kubernetes permissions. Network access alone can be enough when internal services rely on weak authentication, shared credentials, source-IP trust, or the assumption that requests originating inside the cluster are safe.

This internal trust model is especially risky in clusters that host workloads with different security profiles. Public applications, CI runners, test environments, data-processing jobs, monitoring agents, and production services often share the same underlying network. Without segmentation, the workload with the weakest security posture may gain access to the systems with the highest value.

A Compromised Pod Becomes an Internal Reconnaissance Platform

After obtaining code execution in a container, an attacker can begin mapping the surrounding environment. Kubernetes gives workloads several mechanisms that make internal discovery easier.

Cluster DNS provides predictable names for Services. A compromised Pod may attempt connections to names such as database, redis, jenkins, vault, elasticsearch, kibana, prometheus, or grafana. Fully qualified service names can also reveal workloads in other namespaces.

Environment variables, configuration files, mounted Secrets, and application error messages may expose further service names and ports. If the Pod has access to the Kubernetes API, the attacker may query Pods, Services, Deployments, Secrets, ConfigMaps, Nodes, or EndpointSlices. Those resources can identify internal targets with greater accuracy than blind network scanning.

Even a restricted service account may reveal enough information to support lateral movement. Listing Services can expose application names and ports. Reading EndpointSlices can provide Pod IP addresses. Viewing Deployment specifications may reveal environment variables, image names, mounted volumes, and service accounts.

An attacker does not need kubectl to use this information. Standard HTTP clients, shell utilities, scripting languages, or custom binaries can query the API and probe internal endpoints directly.

Missing NetworkPolicy Produces a Flat Pod Network

Kubernetes NetworkPolicy resources provide Layer 3 and Layer 4 traffic controls for Pods. They can restrict which sources may connect to a workload and which destinations a workload may contact. Yet many clusters either do not use NetworkPolicy or apply it only to a small set of sensitive applications.

When no policy selects a Pod, that Pod remains non-isolated. It can accept inbound traffic and initiate outbound connections according to the underlying network configuration. A namespace filled with Pods but no NetworkPolicy is effectively open to the rest of the cluster.

The strongest starting point is a default-deny policy for both ingress and egress. That model places every Pod in the namespace under isolation, then requires separate allow rules for approved application flows.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: application
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

This policy does not define any allowed traffic. Applications will lose connectivity until separate policies permit DNS, required service connections, health checks, monitoring, and approved external destinations.

That operational impact is one reason teams sometimes avoid egress controls. Yet leaving egress unrestricted removes one of the primary barriers between a compromised workload and the rest of the environment.

Ingress Controls Alone Do Not Contain a Compromise

Many Kubernetes deployments focus almost entirely on inbound traffic. Teams restrict access to databases and backend services but allow every Pod to initiate outbound connections without limitation.

Ingress and egress isolation are separate. A workload protected by an ingress policy may still reach other namespaces, node services, cloud metadata endpoints, internal management systems, and the public internet when no egress policy applies.

This creates several paths for an attacker. The compromised Pod can download tools, connect to command-and-control infrastructure, exfiltrate application data, scan internal address ranges, contact the Kubernetes API, or attempt access to cloud services.

Open egress can also expose cloud instance metadata services. In several cloud environments, link-local metadata endpoints can provide instance information, identity tokens, or temporary credentials. A container that reaches the metadata service may gain permissions that extend well beyond the Kubernetes namespace.

Egress policy should permit only the destinations that the application requires. DNS access, internal APIs, databases, telemetry collectors, and approved external services should be declared through narrow rules. Broad CIDR ranges and unrestricted internet access weaken the containment value of the policy.

Clusters with dynamic external dependencies may need an egress proxy, gateway, service mesh, or CNI-specific domain controls. Standard NetworkPolicy operates at the IP and port level and does not provide native filtering by DNS name or HTTP path.

Namespace Selectors Can Create Unintended Trust

NetworkPolicy can permit traffic based on Pod labels, namespace labels, IP ranges, or combinations of those attributes. Small selector mistakes can change the meaning of a rule.

A peer containing both a namespaceSelector and a podSelector requires the source Pod to match both conditions. The Pod must carry the selected label and exist inside a namespace with the selected label.

Placing those selectors into separate peer entries creates an OR condition instead. One entry may allow every Pod from the selected namespaces, and the other may allow selected Pods from the local namespace. A formatting error can turn a narrow cross-namespace rule into access for a much larger group of workloads.

Label governance matters for the same reason. If application owners can assign labels that NetworkPolicy treats as trusted identities, they may be able to place their workloads inside privileged communication groups. An attacker with permission to modify a Pod or Deployment may also attempt to change labels and gain access to protected services.

Security-related labels should be assigned and controlled through restricted deployment pipelines, admission policies, and narrow RBAC permissions. Namespace labels used for trust decisions require the same protection.

Kubernetes Policies Are Additive

NetworkPolicy does not process rules in a top-to-bottom order. There is no first-match behavior and no explicit deny rule that overrides an allow.

When multiple policies select the same Pod, their allowed traffic is combined. A restrictive policy can coexist with another policy that grants broader access. The effective result is the union of every applicable allow rule.

This behavior makes isolated manifest review unreliable. A single policy may appear secure, yet another policy in the namespace may permit the same traffic through a broader selector.

Rules containing empty peer objects can be especially dangerous. An ingress entry such as - {} allows traffic from every source. An egress entry using the same structure allows traffic to every destination. Such rules may be introduced during troubleshooting and left in place after connectivity is restored.

Policy analysis must evaluate the full set of policies that select each workload. Security testing should then confirm the result through real connection attempts rather than relying only on YAML inspection.

CNI Support Determines Whether Policies Work

Kubernetes defines the NetworkPolicy API, but the cluster networking plugin performs enforcement. A cluster can accept NetworkPolicy objects even when the installed CNI does not enforce them.

This creates a false sense of security. Administrators may see policies stored in the API and assume segmentation is active. Packets may still flow without restriction.

Support can also vary by protocol, IP family, host-network behavior, or CNI configuration. A plugin may enforce ordinary Pod traffic but treat traffic involving node addresses, host-networked Pods, or service translation differently.

Policy deployment should include active testing from controlled Pods. Tests should verify that permitted connections succeed and prohibited connections fail. The same checks should run after CNI upgrades, Kubernetes upgrades, service-routing changes, and major policy updates.

Dual-stack clusters require testing over both IPv4 and IPv6. A restriction verified only over one address family may leave a parallel route open through the other.

Service Translation Can Change What Policies See

Kubernetes Services often translate a virtual Service IP into one of several backend Pod addresses. Load balancers, ingress controllers, kube-proxy, and cloud networking components may also perform source or destination translation.

The address observed by NetworkPolicy enforcement can depend on where that enforcement occurs in the packet path. A policy may see the original client address, a node address, a load balancer address, or a translated backend address.

This can make IP-based rules unreliable when teams assume a particular translation order. A rule intended to allow one external proxy may instead see all traffic as originating from a node. A rule intended to block an external range may be evaluated after destination translation and never see the original address.

Pod selectors and namespace selectors are usually better suited for in-cluster communication. CIDR-based rules still have value for external services, node networks, metadata endpoints, and fixed infrastructure, but they require testing against the deployed network path.

Host-Networked Pods Can Bypass Normal Assumptions

Pods configured with hostNetwork: true share the node’s network namespace. They use node addresses rather than normal Pod addresses and may be treated as node traffic by the CNI.

NetworkPolicy behavior for host-networked Pods varies across implementations. Pod and namespace selectors may not identify the traffic in the expected way. A host-networked workload may reach node-local services, management interfaces, or other systems through paths that ordinary Pod policies do not cover.

Ingress controllers, storage components, monitoring agents, security sensors, and network utilities often use host networking. These workloads also tend to receive greater privileges than ordinary applications.

A compromise in one of them may provide direct access to the node network, kubelet endpoints, container runtime sockets, or host services. Access to hostNetwork, hostPID, hostIPC, host ports, privileged mode, and host-mounted paths should be heavily restricted through Pod Security Admission and separate admission controls.

Privileged infrastructure Pods should also be separated from untrusted workloads through node pools, taints, tolerations, and scheduling constraints.

NodePort and External Exposure Create New Entry Points

Kubernetes Service types can expose workloads outside the cluster. Misconfigured NodePort, LoadBalancer, or external IP settings can make internal services reachable from networks that were never intended to access them.

A NodePort Service opens a port on each eligible node and forwards traffic to the Service endpoints. An administrative dashboard, database, metrics service, or internal API accidentally exposed through NodePort may become accessible from adjacent networks or the internet, depending on firewall and routing rules.

Cloud load balancer annotations can create similar exposure. A Service intended to receive an internal load balancer may receive a public one if an annotation is omitted or incorrect. Source-range restrictions may also be absent, leaving the service reachable from any address.

Service creation should be controlled through RBAC and admission policies. Workloads should not be able to create public LoadBalancer or NodePort Services without approval. Exposure settings, annotations, source ranges, and external addresses should be validated before admission.

Kubernetes API and Kubelet Access Accelerate Lateral Movement

A Pod that can reach the Kubernetes API server has a direct path to the cluster’s management plane. Authentication and RBAC still apply, but network reachability gives an attacker the opportunity to use any credentials found in the container.

Kubernetes commonly mounts a service account token into Pods. If the workload does not require API access, token mounting can be disabled with automountServiceAccountToken: false.

When API access is needed, the service account should receive only the permissions required by that application. Wildcard verbs, wildcard resources, cluster-wide roles, Secret access, workload creation, impersonation, and privilege-escalation permissions can turn a compromised Pod into a cluster administration channel.

Permission to create Pods or Deployments deserves particular attention. A user or service account that can create a workload may be able to select a more privileged service account, mount accessible Secrets, attach persistent volumes, run a dangerous image, or request host-level features.

Kubelet access presents a separate risk. Depending on authentication and authorization settings, kubelet endpoints may expose Pod metadata, logs, metrics, or command execution capabilities. Pod networks should not receive unrestricted access to kubelet management ports.

The API server, kubelet, container runtime, and node administration interfaces should be protected through private networking, firewalls, restricted address ranges, and host-level controls in addition to Kubernetes policy.

Lateral Movement Rarely Depends on One Failure

A cluster-wide incident usually develops through several smaller weaknesses.

An attacker may first exploit an internet-facing application. The compromised Pod has unrestricted egress, allowing it to query DNS and scan internal services. The attacker discovers a cache server in another namespace and finds that it lacks authentication.

Data from the cache reveals application credentials. The attacker uses those credentials to access an internal API, then recovers a Kubernetes service account token from a configuration file or mounted volume. The token permits listing Pods and reading Secrets in the namespace.

One Secret contains credentials for a CI system. The CI system has permissions to deploy workloads into production. The attacker uses that access to create a new Pod under a privileged service account, then reaches additional namespaces or node resources.

Each individual control may appear only slightly permissive. Together, they create a complete route from one application flaw to cluster-wide access.

Detection Requires Network and Control-Plane Telemetry

Standard NetworkPolicy does not create complete security logs on its own. Defenders need telemetry from the CNI, eBPF sensors, cloud flow logs, host firewalls, ingress controllers, service meshes, and Kubernetes audit logs.

Network detections should identify Pods connecting to large numbers of internal addresses, repeated probes against administrative ports, new cross-namespace communication, direct access to node IPs, metadata service requests, and outbound connections to previously unseen external destinations.

Kubernetes audit logs should be reviewed for Secret access, EndpointSlice enumeration, service account token requests, Pod creation, DaemonSet creation, privileged workload deployment, pods/exec, pods/attach, policy changes, Service exposure changes, and edits to security-sensitive labels.

The strongest detections correlate several events. A public-facing Pod that begins scanning internal services, accesses the API, reads a Secret, and then opens a shell in another workload presents a much clearer lateral-movement pattern than any one event viewed alone.

Segmentation Must Be Tested as Part of Application Delivery

NetworkPolicy should be treated as part of the application’s security model rather than an optional cluster setting. Every permitted connection represents an explicit trust relationship between workloads.

New namespaces should receive default-deny ingress and egress policies at creation. Application teams should declare required communication paths through version-controlled policy manifests. DNS, monitoring, health checks, service dependencies, and approved external destinations should receive narrow allow rules.

Policy tests should run during deployment and after infrastructure changes. A test workload should confirm both allowed and blocked paths. Security teams should also verify that node interfaces, metadata services, management APIs, and unrelated namespaces remain unreachable.

Clusters should separate highly trusted infrastructure from public or user-controlled workloads. Dedicated node pools can limit the exposure of controllers, security agents, storage systems, CI components, and other privileged services.

Kubernetes gives organizations the tools to create strong workload boundaries, but those boundaries do not appear automatically. Without verified segmentation, one compromised container can become an internal access point to the rest of the cluster.

The difference between a contained application incident and a cluster-wide breach often comes down to which network paths were left open before the attacker arrived.

How Can Netizen Help?

Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.