Many companies run into the same problem after adopting MSA (Microservices Architecture).

What data is moving between services right now? Which service is calling which one? Are there internal APIs exposed without authentication?

The number of services keeps growing, but service-to-service traffic visibility often does not.

This becomes even more serious in Kubernetes environments, cloud-native infrastructure, and microservices-based systems, where internal traffic quickly becomes complex.

External traffic is usually managed through WAFs, API gateways, and firewalls. But Kubernetes internal traffic—commonly called East-West Traffic—is still a blind spot in many organizations.

At weranaSeeker, we have analyzed real customer environments to solve this issue, and one conclusion became clear:

For internal service traffic visibility, eBPF is often the most practical approach.

---

Why Is Internal Traffic Monitoring So Difficult in MSA Environments?

In microservices architectures, many services continuously call each other through APIs.

For example:

• Order Service → Payment Service
• Payment Service → User Service
• User Service → Notification Service
• Batch Service → Settlement Service
• Admin Service → Legacy System

At first, the architecture may look simple. But as services grow, dependencies become difficult to track.

1. Real Connections Drift from Documentation

Architecture diagrams may show A → B.

In production, the real path may become:

A → C → D → External System

2. Even Development Teams Lack Full Visibility

Each team knows its own service well.

But very few teams know the entire runtime communication flow across all services.

3. Security Teams Struggle with Lateral Movement

External attacks may be detected.

But internal movement between workloads often goes unnoticed.

---

Is a Service Mesh Like Istio the Answer?

Many organizations consider service mesh platforms such as Istio and Envoy.

They offer clear advantages:

• L7 traffic visibility
• Fine-grained policy control
• mTLS support
• Advanced routing capabilities

But real-world operations also introduce challenges.

Sidecars Scale with Every Pod

If you have 50 services, you may also have 50+ sidecars.

Higher CPU and Memory Usage

Each Pod runs an additional Envoy proxy, increasing resource overhead.

Troubleshooting Becomes Harder

When something breaks, is it:

• The application?
• The proxy?
• Mesh policy?
• DNS?

This increases operational complexity.

Existing Environments Must Change

For many enterprises, asking them to adopt a full service mesh before solving visibility problems is unrealistic.

---

Why We Chose eBPF

eBPF operates at the Linux kernel level and observes networking and system behavior directly.

That means:

• No application code changes
• No Pod restarts
• No sidecars required
• Language/framework independent
• Works across Kubernetes, VMs, and bare metal

It enables internal traffic monitoring without major architectural changes.

---

How Can eBPF Trace Service-to-Service Communication?

eBPF can trace the moment an application sends data through a socket.

For example, at a kernel function like tcp_sendmsg, it can inspect metadata such as:

• HTTP Method
• URL Path
• Host Header
• Partial Authentication Header
• Traffic Direction
• Connection Metadata

Examples:

• POST /internal/charge
• GET /user/profile
• Authorization: Bearer ...

Then, by correlating with:

• PID
• Container ID
• Pod
• Namespace

You can identify:

Which service Called which service Through which API

This enables Kubernetes internal traffic visibility in real time.

---

3 Common Issues Found in Real Customer Environments

1. Internal APIs Without Authentication

This is one of the most common findings.

Internal APIs opened for convenience during development often remain exposed in production.

/internal/*
/admin/*
/batch/*

In one environment, /internal/charge was being called without authentication.

---

2. Connections Missing from Architecture Documentation

After learning normal communication patterns, new unexpected connections can be detected.

Examples:

• Batch Service → Payment Service directly
• Admin Service → Database bypass access
• New Pod → Sensitive API access

We have seen cases where test code was accidentally merged into production branches.

---

3. Plain HTTP Still Exists Internally

As service counts grow, TLS gaps often remain unnoticed.

In one customer environment, 6 out of 28 services were communicating over plain HTTP.

Typical causes:

• Legacy integrations
• Temporary configurations left in place
• Certificate renewal failures
• “It’s internal, so it’s fine” assumptions

Source: Cilium Project (Apache 2.0 License)

---

eBPF Also Has Limitations

TLS Payload Content Is Not Directly Visible

Encrypted payload contents are not readable after encryption.

gRPC Is More Complex

gRPC uses HTTP/2 multiplexing, making parsing more complex than HTTP/1.1.

L7 Inspection Uses Some CPU

There is some overhead for deep inspection, but generally lower than sidecar-based approaches.

---

Current Capabilities

Capability	Status
L4 Connection Detection	✅
HTTP Header Identification	✅
Service Topology Auto Mapping	✅
New Connection Detection	✅
TLS Usage Detection	✅
gRPC Method Analysis	In Progress
TLS Payload Inspection	Roadmap

---

Why Internal Visibility Matters Now

Modern attacks increasingly focus on movement after initial access.

• Stolen credentials
• Abuse of legitimate services
• Internal API calls
• Database lateral movement
• Sniffing plaintext traffic

Without East-West Traffic Visibility, post-compromise movement is easy to miss.

---

What weranaSeeker Provides

weranaSeeker uses eBPF to deliver:

• Kubernetes service communication flow analysis
• Hidden internal API discovery
• New abnormal connection detection
• Plaintext traffic detection
• Automatic service map generation
• Service-to-service communication reports

---

30-Day Free POC Available

You can validate how much of your Kubernetes internal traffic is currently visible.

✔ Automatic service relationship analysis ✔ Plaintext traffic detection ✔ Hidden internal API discovery ✔ Operational impact measurement

We deploy in real customer environments and review results together.

---

Conclusion: In the MSA Era, Internal Visibility Is a Competitive Advantage

As the number of services grows, so do:

• Operational complexity
• Security risk
• Root-cause analysis difficulty

Today, it is no longer enough to defend only the perimeter.

Internal traffic visibility is now essential.

If service-to-service traffic is invisible in your MSA environment, eBPF may be the most practical option.