Unencrypted east west traffic creates risk because anyone who can observe the network may learn how the cluster works. DNS queries and metrics polling can reveal service relationships, operational patterns, and other clues that help an attacker pivot or combine weaknesses. Even if those channels are not the main security focus, they can still expose useful intelligence.
Why unencrypted east west traffic matters inside a cluster
Unencrypted east west traffic removes confidentiality from the most operationally sensitive part of the environment: service-to-service communication. In a Kubernetes cluster, that traffic often carries identifiers, routing hints, API calls, and telemetry that reveal how workloads are connected. Even when the payload is not directly sensitive, the traffic pattern itself becomes intelligence that can be observed, copied, and used.
This matters because east west traffic is usually trusted by design. Once an attacker can observe it, they do not need to break encryption to learn where to move next. The exposure is often enough to map dependencies, identify higher-value services, and look for weaker paths that are easier to pivot through.
In practice, the risk is not limited to packet contents. Repeated DNS lookups, health checks, metrics scraping, and service discovery can expose the shape of the platform. That creates a reconnaissance layer inside the cluster, which can be combined with other weaknesses such as overbroad access, exposed endpoints, or poor network segmentation.
What attackers and observers learn from plain east west traffic
Plaintext traffic can reveal which services talk to each other, how often they communicate, and which systems are operationally central. That is enough to build a service map without direct access to the control plane. For a defender, the practical concern is that an internal observer may infer topology, trust boundaries, and movement opportunities from routine traffic alone.
Even when no single message is sensitive, the cluster can leak useful context. DNS names may identify namespaces or workloads, metrics polling can show naming conventions and scrape targets, and repeated connections can show which services are dependencies for others. Those clues reduce attacker effort and make later exploitation more targeted.
Encrypted east west traffic does not eliminate all risk, but it does force an attacker to work harder to collect the same intelligence. That raises the cost of reconnaissance and limits passive observation, which is especially important in dense multi-service environments where many components share the same network plane.
Why encryption is only one layer, not a complete fix
Encrypting east west traffic helps protect confidentiality in transit, but it does not by itself solve authorization, segmentation, or workload trust. A cluster can still be exposed if services accept overly broad connections, if identities are reused across environments, or if internal endpoints remain reachable without meaningful policy enforcement. For that reason, transport protection works best alongside strict service identity and explicit network policy.
Good practice is to treat unencrypted east west traffic as both a visibility problem and a trust problem. If traffic can be read, it can also be mined for operational intelligence. If traffic can be replayed or impersonated in a weakly controlled environment, the same lack of protection can turn observation into abuse.
That is why many practitioners pair service-to-service encryption with workload identity and micro-segmentation. The value is not just secrecy, it is shrinking what an internal observer can infer and what a compromised workload can reach.
Risk and Threat Considerations
Unencrypted east west traffic creates a reconnaissance surface inside the cluster. An attacker or curious insider who can observe internal network flows may learn service relationships, operational cadence, and dependency patterns that help identify the best pivot point or the weakest exposed path.
Failure mechanism: Plaintext internal traffic, unprotected DNS, and readable telemetry expose metadata and sometimes payload details that let an observer reconstruct cluster behaviour without control-plane access.
Impact: The exposed intelligence can shorten attacker dwell time, improve lateral movement decisions, and make follow-on compromise more precise by revealing which services matter most.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Unencrypted internal traffic can expose credentials, tokens, and sensitive routing details in transit. |
| NHI-08 — Environment Isolation | Plain east west traffic reduces isolation by exposing patterns across cluster boundaries. | |
| NHI-10 — Human Use of NHI | Observed service traffic can reveal how non-human workloads operate and interact in the cluster. | |
| Recommendation — Encrypt internal traffic and remove any secrets from observable service communications. Separate environments and require encrypted, policy-controlled service-to-service paths. Limit human exposure to workload traffic details and monitor for unnecessary inspection paths. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Internal traffic confidentiality is the core issue when east west traffic is left unencrypted. |
| AC-4 — Information Flow Enforcement | Cluster traffic patterns need enforced boundaries so observed paths do not become open pivots. | |
| Recommendation — Protect internal traffic with approved encryption in transit mechanisms. Enforce service-level flow restrictions to constrain what internal observers can reach. | ||
| NIST Zero Trust (SP 800-207) | – — Never trust, always verify | Kubernetes east west traffic is a zero trust use case where internal traffic cannot be assumed safe. |
| Recommendation — Treat every service-to-service request as untrusted and verify it explicitly. | ||
| OWASP ASVS | V12 — Secure Communication | The question is about communication confidentiality between internal services. |
| Recommendation — Require encrypted channels for service communication and verify certificate handling. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-Transit is Protected | The cluster risk arises from data moving across internal network paths without protection. |
| Recommendation — Protect data in transit on all internal service paths. | ||
Practitioner Guidance
What to prioritise: Focus first on the traffic that reveals the most about service relationships, especially DNS, service discovery, metrics collection, and controller-to-workload communication. Those channels often disclose more about the environment than the main application payloads.
What to verify: Confirm that internal traffic requiring confidentiality is actually encrypted in transit, and that the services handling it are not still leaking equivalent information through logs, metrics labels, or cleartext side channels. If the same dependency graph is visible elsewhere, encryption alone has not materially reduced exposure.
Practitioner takeaway: The key judgement is not whether east west traffic is sensitive in the usual data-classification sense, but whether its visibility allows an observer to map the cluster and choose a better attack path.
