Service Graph

Most network security watches the edge: what comes in, what goes out. The service graph watches the traffic that never crosses it — service to service, pod to pod, inside your own estate.

It answers three questions:

1. What is actually talking to what? Observed from real traffic, not from a diagram someone drew.
2. What is supposed to talk to what? Declared by you.
3. Where do those two disagree? That difference is the finding.

Identity, not addresses

In a cluster, an IP address is a poor name for a workload. Pods are rescheduled, addresses are recycled, and a rule written against 10.42.3.17 is wrong the moment something restarts.

The service graph resolves traffic back to the workload behind it, so policy can be written against names that survive a restart:

Instead of	Write
10.42.3.17	the payments workload
A CIDR that happens to cover a namespace	the production namespace
A pod IP range	a label selector

Amygdala exposes these as ordinary rule fields — source and destination namespace, workload, and labels — so a firewall rule can name a service instead of an address.

Declared edges

You declare which services are allowed to reach which. Every observed connection is then classified against that declaration:

	Meaning
Declared	This edge is in your policy. Expected traffic
Undeclared	Real traffic with no matching declaration. Either a gap in the policy or something that should not be happening
Violation	Traffic that contradicts the declaration

The classification is available to rules, so a policy violation is not just a dashboard entry — it can be the condition that triggers a block.

Start by watching, not blocking

Declared-edge policy is most useful in the order: observe real traffic first, promote what is legitimate into declarations, then enforce. Writing declarations before you have seen the traffic tends to produce an allow-list that is missing exactly the edges you forgot about.

Amygdala's log action is built for this — a rule can record what it would have blocked without acting, so you can read the consequences before accepting them.

Enforcement stays on the fast path

The graph itself is not consulted per packet. Agents enforce using flat lookups on the packet path; the graph is built and queried out of band, by the platform. That keeps east-west policy enforcement as cheap as any other rule, no matter how large the graph gets.

Querying it

The graph is served by the platform's service-graph API, reachable at /v1/service-graph on a Cerebellum deployment, and surfaced in the dashboard. Cross-site correlation — the same workload seen from more than one cluster — is Cerebellum's job rather than the agent's.

Use cases

• Find the edges nobody documented — the batch job that quietly reaches the production database, the service still calling a dependency that was supposed to be retired.
• Microsegment without maintaining IP lists. Declare that only api may reach payments, and let workload identity keep that true through every reschedule.
• Turn a policy violation into a block rather than a ticket, once you trust the declarations.
• Scope the blast radius of a compromise by knowing what a workload could have reached from where it sat.

See also

• Amygdala — the rule engine that acts on workload identity and edge classification
• Access Rules — address-level filtering, the north-south counterpart
• Architecture overview — where the platform pieces sit