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

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

• Mapper - the mapper is deployed once per cluster, and receives traffic information from the sniffer and watchers, and resolves the information to communications between (service identities)[/service-identities].
• Sniffer - the sniffer is deployed to each node using a DaemonSet, and is responsible for capturing node-local DNS traffic and inspecting open connections.
• Kafka watcher (beta) - the Kafka watcher is deployed once per cluster and is responsible for detecting accesses to Kafka topics, which services perform those accesses and which operations they use.
• Istio watcher (beta) - the Istio watcher is deployed once per cluster and queries Istio Envoy sidecars for HTTP traffic statistics, which are used to detect HTTP traffic with paths. Currently, the Istio watcher has a limitation where it reports all HTTP traffic seen by the sidecar since it was started, regardless of when it was seen.

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.

Kafka logs

The Kafka watcher periodically examines logs of Kafka servers provided by the user through configuration, parses them and deduces topic-level access to Kafka from pods in the cluster. The watcher is only able to parse Kafka logs when Kafka servers' Authorizer logger is configured to output logs to stdout with DEBUG level.

Istio sidecar metrics

The Istio watcher periodically queries for all pods with the security.istio.io/tlsMode label, queries each pod's Istio sidecar for metrics about connections, and deduces connections with HTTP paths between pods covered by the Istio service mesh.

Deploying the network mapper

To deploy the network mapper, use the Helm chart.

Monitoring the network mapper

All network mapper pods expose a Prometheus metrics endpoint on port 2112, on /metrics.

Pod annotations

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

Annotation	Description
intents.otterize.com/service-name	Used for service identity resolution.