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:
checkoutservice in namespace otterize-ecom-demo calls:
frontend in namespace otterize-ecom-demo calls:
loadgenerator in namespace otterize-ecom-demo calls:
recommendationservice in namespace otterize-ecom-demo calls:
How does the network mapper work?
- 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 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
ss. The IP addresses are used for the service identity resolving process, as above.
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
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
You can override the service name the network mapper uses when it computes the service name using a pod annotation.
|Used for service identity resolution.|