Network mapper

The Otterize network mapper creates a map of in-cluster traffic by (1) capturing DNS traffic and (2) inspecting active connections in the same manner netstat does, then resolving the IP addresses participating in connections to the Pods, and crawling up the ownership of the Pod until it reaches the root object. See Service identities to learn more on how service name resolving happens. The network mapper continues building the network map as long as it's deployed.

You can then use the Otterize CLI to list the traffic by client, reset the traffic the mapper remembers, or export it as JSON or YAML, which serves as ClientIntents Kubernetes resources). ClientIntents can be consumed by the Otterize intents operator to apply network policies or Kafka ACLs to your cluster, implementing intent-based access control.

To get started, follow the quick hands-on tutorial or the quick, more visual tutorial. Here's an example output for running the network mapper following the example:

cartservice in namespace otterize-ecom-demo calls:
 - redis-cart
checkoutservice in namespace otterize-ecom-demo calls:
 - cartservice
 - currencyservice
 - emailservice
 - paymentservice
 - productcatalogservice
 - shippingservice
frontend in namespace otterize-ecom-demo calls:
 - adservice
 - cartservice
 - checkoutservice
 - currencyservice
 - productcatalogservice
 - recommendationservice
 - shippingservice
loadgenerator in namespace otterize-ecom-demo calls:
 - frontend
recommendationservice in namespace otterize-ecom-demo calls:
 - productcatalogservice

How does the network mapper work?

Components

• Sniffer - the sniffer is deployed to each node using a DaemonSet, and is responsible for capturing node-local DNS traffic and inspecting open connections.
• Mapper - the mapper is deployed once, and resolves service names using the Kubernetes API with traffic information reported by the sniffers.

DNS responses

DNS is a common network protocol used for service discovery. When a pod (checkoutservice) tries to connect to a Kubernetes service (orderservice) or another pod, a DNS query is sent out. The network mapper watches DNS responses and extracts the IP addresses, which are used for the service identity resolving process.

Active TCP connections

DNS responses will only appear when new connections are opened. To handle long-lived connections, the network mapper also queries open TCP connections in a manner similar to netstat or ss. The IP addresses are used for the service identity resolving process, as above.

Deploying the network mapper

To deploy the network mapper, use the Helm chart.

Pod annotations

You can override the service name the network mapper uses when it computes the service name using a pod annotation.

Annotation	Description	Default
intents.otterize.com/service-name	Otterize-wide override for this service's name.	See Service identities