Calico Platform

Evaluates proposed segmentation policies against observed traffic to identify what legitimate connections would be blocked, enabling policy validation without a production enforcement change.

Enriches raw flow and asset records with context such as owning process, user, application, environment, cloud tags, CMDB attributes and threat intelligence, and turns that context into labels that policies reference directly, so rules are written in business terms (application, environment, role) rather than addresses and ports. Products differ in attribute breadth, process- and payload-level depth, and how much labeling is automatic rather than manual.

Produces prebuilt reports tailored to specific audiences and compliance frameworks that evidence segmentation controls for auditors (PCI DSS, HIPAA, NIS2, DORA and similar), together with diagnostics that show where observed traffic diverges from intended policy and why a given connection was allowed or blocked. Products differ in framework coverage, audience-specific report depth, and the quality of policy troubleshooting.

Proposes least-privilege allow-list rules automatically from observed flows, labels and templates, and manages them through the full lifecycle of creation, testing, enforcement, tuning and retirement, so segmentation is not built by writing rules by hand. Products differ in recommendation quality, template coverage for common applications and compliance zones, and support for iterative refinement before enforcement.

Enforces segmentation policy on the workload itself through a host agent or existing endpoint hooks (operating system firewall, eBPF, an EDR agent already deployed), so the policy travels with the workload across data center, cloud and endpoint locations and gives per-process visibility. Products differ in operating system coverage, resource overhead, kernel or user-mode operation, and whether an existing EDR agent can be reused instead of deploying a new one.

Detects threats from the product's own segmentation telemetry and enforcement points, for example intrusion detection and prevention on east-west traffic, anomalous flow and process behavior, and deception decoys, rather than relying solely on an external EDR or NDR to raise the alert. Products differ sharply by enforcement architecture: host-agent and hypervisor-based solutions with process or payload visibility can detect natively, while network- and NAC-based solutions without endpoint visibility generally cannot. Some pair detection with enforcement to virtually patch protected workloads.

Renders the discovered assets, their flows and the current policy state as an interactive map that can be viewed at data center, application, workload and connection level, showing which traffic is allowed, blocked or not yet governed, so teams can author policy and investigate incidents from the same view. Products differ in readability at scale, filtering and drill-down, and whether the map supports policy authoring directly.

Extends the same segmentation policy model into Kubernetes and container environments, enforcing at pod, namespace and service level through CNI or eBPF hooks, sidecars or native NetworkPolicy objects, so container traffic is governed by the same labels and rules as virtual machines and bare metal instead of a separate container-only tool. Products differ in whether Kubernetes support is enforcement or visibility only, distribution coverage (managed cloud Kubernetes, OpenShift, self-managed), and Layer 7 awareness.

Discovers the actual north-south and east-west communication flows between workloads and devices by observing live traffic, producing the dependency data that allow-list policy is built from instead of hand-documented application maps. Products differ in flow sources (host agent, network sensors or switch telemetry, cloud flow logs, virtual switch) and therefore in how completely agentless assets are covered.

Orders network policies into tiers (for example security, platform, application) so higher-priority security team rules are evaluated before namespace-level developer policies and cannot be overridden.

Routes selected pod or namespace outbound traffic through gateway pods that SNAT to a small pool of stable source IPs so external firewalls can allow-list Kubernetes workloads.

Enforces mutual TLS on every service-to-service connection using X.509 workload identities (SPIFFE), so traffic between pods is encrypted and authenticated by service identity rather than IP and port.

Captures and logs all pod-to-pod network flows including service mesh traffic, providing full observability for anomaly detection and policy validation.

Enforces DNS-based and IP-based egress policies for pod outbound traffic, preventing C2 communication, data exfiltration, and unauthorized external API calls.

Analyzes observed pod-to-pod traffic and generates Kubernetes NetworkPolicy manifests that allow only observed legitimate connections, reducing policy authoring to review and approval.

Enforces policy on HTTP paths, gRPC, Kafka, and service identity rather than IP and port, so rules survive pod churn and constrain what each service may do.

Enforces network policies using eBPF programs attached to kernel hooks, providing lower overhead and higher throughput than iptables-based NetworkPolicy enforcement.