What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Feature split between Calico Open Source, Enterprise and Cloud: confirm with vendor
- Current dataplane options and platform support matrix: verify against project documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Calico is a CNI plugin first and a security control second, and the two are inseparable. It assigns pod addressing and handles routing between nodes, commonly by distributing routes with BGP rather than by wrapping traffic in an overlay, though overlay modes exist where the underlying network will not carry pod routes. Because Calico programs the datapath, it is also positioned to filter it.
Policy enforcement happens in an agent on each node, Felix, which translates policy objects into dataplane rules. Which dataplane depends on how you run it: iptables is the traditional target, an eBPF dataplane replaces that with programs attached at the network interface, and a Windows dataplane exists for mixed clusters. Beyond the standard Kubernetes NetworkPolicy object, Calico defines its own policy types adding ordering, explicit allow and deny actions, and policy applying across namespaces or to host network interfaces themselves. Commercial tiers layer on flow log collection, a service graph, DNS based egress policy, policy staging so you can see what a rule would have blocked before enforcing it, and compliance reporting.
Where it fits
This is cluster infrastructure owned by a platform team, chosen at build time because swapping a CNI in a live cluster is disruptive. Policy authorship, though, is shared: service owners usually know which services should talk to which, and security teams set the default deny posture and the egress boundaries. Nothing here is useful until your workloads carry meaningful, consistent labels, because labels are the entire addressing scheme for policy.
Strengths
- Policy follows workload identity through labels rather than IP addresses, so rules survive pods being rescheduled and rebuilt.
- The eBPF dataplane removes a large iptables rule set from the hot path and preserves original source addresses for services.
- Global network policy and host endpoint protection cover nodes and cross namespace traffic, which plain Kubernetes policy cannot express.
- The open source tier is fully functional for segmentation.
Limitations
- Default deny is easy to enable and easy to get wrong, and a mistake breaks production traffic rather than logging something.
- Open source Calico gives enforcement but little visibility, so understanding why a connection dropped means manual tracing unless you buy the commercial tier.
- Layer 3 and 4 policy cannot see inside encrypted application traffic or make identity decisions the way a service mesh with mutual TLS can.
Who it suits
The right choice for platform teams that need real segmentation between Kubernetes workloads and will maintain label discipline and policy as code. Less suitable for a single small cluster where the cluster boundary is the only trust boundary anyone cares about, and not a substitute for a service mesh if you need application layer authorization.
Used Calico? Recommend it under your own name and title.
Recommend this tool