Kubernetes, Cilium & Calico network policy visibility

Network Policies control pod-to-pod and pod-to-external traffic at the network level. Radar supports standard Kubernetes NetworkPolicy, Cilium policies, and Calico policies, showing which policies exist and which workloads they select, which workloads no policy selects, and - when Hubble reports a policy drop - what the plugin recorded and what Radar can determine from the current Kubernetes NetworkPolicies. Applicable Cilium policies are listed, but their rules are not evaluated. Investigating dropped traffic? With Hubble as the traffic source, expand a dropped flow to see the reason the plugin reported and, for policy drops, Radar’s check of the current Kubernetes NetworkPolicies - the first section below. Asking whether a Service is reachable at all, before any traffic is sent? That’s Reachability, which predicts Kubernetes NetworkPolicy effects on a Service path and can probe that path.

​

Why was this flow dropped?

With Hubble as the traffic source, expand a dropped flow in the Traffic view to see the reason the network plugin reported. For policy drops, Radar also shows the deny policy the plugin named, if any, and checks the current Kubernetes NetworkPolicies against that connection. The panel answers in that order: what the plugin recorded, what current policies say, and what Radar could not check. Radar reads policies as they are now and says so. The plugin’s deny attribution and Radar’s current-policy check are separate things, and the panel keeps them apart. When missing information - the pod is gone, the flow record has no direction, you cannot read the peer’s namespace - keeps Radar from completing the check, the panel explains why instead of guessing. Applicable Cilium policies are listed, but their rules are not evaluated. The common case is a default-deny policy with nothing that allows the client. Cilium reports the drop as a policy drop but names no policy, because no rule matched. Radar’s own check names the policy that isolates the pod and explains what it does. When the plugin does name the policy - an explicit Cilium deny rule - that is the headline, shown if you have permission to read that policy. The current Kubernetes NetworkPolicy check appears under it as a note; it may find an allow, no matching allow, or an incomplete result. Cilium policies can allow or deny traffic on their own terms, alongside Kubernetes ones, and Radar does not evaluate their rules. So when a Cilium policy governs the pod in the flow’s direction, Radar states the Kubernetes-only result as a result, lists the Cilium policy as can’t evaluate, and does not call the connection allowed or denied. Each policy row says what it does to this connection in plain words: allows this traffic, no matching allow rule, or can’t evaluate. NetworkPolicies combine their allow rules, so a policy with no matching rule does not override another policy’s allow; the panel shows this reminder when several policies apply and at least one has no matching allow rule. Radar runs the current-policy check only when the plugin reports a policy drop. For other drops (an unroutable address, a malformed packet) the panel shows the reported reason and says that Radar checks NetworkPolicies only for policy drops. If the plugin reported no reason, the panel says Radar cannot tell whether a policy was involved. A policy drop over a protocol other than TCP, UDP or SCTP cannot be checked against port rules, and the panel says so. The panel shows when the flow was seen and when the policies were checked, and refreshes every 30 seconds while the row is open. Policies may have changed since the drop: a current allow does not confirm that a new connection will succeed. What the panel does not do yet: propose the rule that would allow the traffic, or tell you whether a policy changed after the drop. The panel shows only what you could read yourself: listing policies and reading the pod in that namespace are required, a peer pod or Namespace you cannot read is left unresolved, and a policy name reported by the plugin is withheld when you cannot list policies of that kind. In the Helm chart, the Cloud cluster-read role grants Cilium policy reads under rbac.crdGroups.cilium so Radar can identify the Cilium policies that apply; it still does not evaluate their rules.

​

What Radar Shows

Topology: Kubernetes, Cilium, and Calico policy nodes appear in the topology graph with edges connecting them to the Deployments, StatefulSets, and DaemonSets they protect. Calico matching evaluates workload, namespace, and service-account selectors. Staged Calico policies use dashed edges and preview styling so they are not mistaken for enforced protection; a staged policy whose stagedAction is Delete or Ignore draws no edge at all, because promoting it would remove protection rather than add it. Dashboard Coverage Card: The home dashboard includes a Network Policy Coverage card showing total policy count, the percentage of workloads covered by at least one enforced policy, and a count of uncovered workloads. When staged Calico policies exist, it separately shows projected coverage if those policies were applied. That projection can be lower than today’s coverage - a staged deletion removes the protection of the policy it names - and the bar marks the part that would be lost. Policy Flow Diagram: Each NetworkPolicy detail drawer includes a visual flow diagram showing ingress and egress rules as a directional graph - sources on the left, targets on the right, with ports and protocols labeled. Quickly understand what a policy allows without reading YAML. Standard NetworkPolicy Detail View:

• Pod selector and namespace selector rules, shown the way Kubernetes applies them: a peer with both selectors is one condition (pods matching X in namespaces matching Y), not two
• Ingress and egress rules with CIDR blocks, ports, port ranges, and protocols
• Policy types as the API server applies them: a policy with no policyTypes isolates ingress, and egress only when it has egress rules
• Related resources showing protected workloads

Cilium Policy Detail View:

• Endpoint selector targeting
• Ingress/egress rules with allow and deny semantics
• Cilium-specific entity selectors (world, cluster, host)
• CIDR rules, port/protocol specifications
• Related workloads with clickable links

Calico Policy Detail View:

• Flow diagram for ordered ingress and egress rules, including Allow, Deny, Log, and Pass actions
• Workload, namespace, and service-account selectors
• Tier, order, policy types, pre-DNAT, apply-on-forward, and do-not-track settings
• Calico entities, CIDRs, ports, protocols, HTTP matches, and ICMP matches
• Staged action and preview styling for staged policy variants

Calico Infrastructure Detail Views: IPPool details show CIDR, encapsulation, NAT, block size, assignment mode, and node selectors. HostEndpoints show interface, expected IP addresses, profiles, and a link to the owning Node. Tier details show order and default action, and policies link back to their Tier. Radar recognizes both projectcalico.org and crd.projectcalico.org. A cluster running the Calico API server serves the same stored policies under both, so each policy appears once, identified by kind, namespace and name. The API group stays part of resource navigation and authorization - it is what keeps Calico NetworkPolicy distinct from Kubernetes networking.k8s.io NetworkPolicy - and a policy is shown to anyone authorized to list it under either group, since either grant is enough to read it.

​

Supported Resources

​

Calico Coverage Limits

Radar statically evaluates Calico selectors against workload pod templates and the Namespace and ServiceAccount objects it can read. The result describes declared policy coverage, not live CNI enforcement or packet-level behavior. Missing labels or RBAC-restricted resources can prevent a relationship from being inferred, and staged policies are never included in enforced coverage. The projected “if staged” figure assumes every staged policy is promoted at once; it is a projection of the declared rules, not a simulation of what the data plane would do.