Repository navigation
fix(connectivity): kagent controller cannot reach atenet-router #827
Description
Problem
On a cluster where Cilium enforces this chart's policies, the kagent controller's requests to atenet-router:8080 are dropped and no turn reaches an actor: the rendered substrate-atenet-router policy (helm/agent-platform-connectivity/templates/substrate/netpol.yaml) was observed admitting pods labelled app.kubernetes.io/name: kagent + app.kubernetes.io/component: controller in the Substrate namespace (ate-system), while the kagent chart renders the controller into the kagent namespace. The lab renders the policies without enforcing them, so it never shows this.
The template selects $kagentNs (.Values.kagent.namespaceOverride, else .Release.Namespace) in both flavours (the Cilium fromEndpoints and the Kubernetes namespaceSelector), and the controller's own egress policy (templates/kagent/netpol.yaml) opens the router in the Substrate namespace. The rendered policy on an enforcing cluster has to be read against that: a release whose values leave kagent.namespaceOverride empty falls back to the connectivity release namespace, which is not where the controller runs.
Proposed solution
Derive the router's ingress selector from the one helper that names the namespace the kagent chart renders the controller into (the helper the kagent policies use), never from the release namespace; render it with the controller's selector labels as the kagent chart defines them (kagent.controller.selectorLabels). make verify-kagent-netpol asserts, in both flavours, that substrate-atenet-router admits the controller from that namespace on 8080. The rendered policy on an enforcing cluster is read and a turn proven after the fix.
Acceptance criteria
- On a cluster where Cilium enforces, a turn from the kagent controller reaches an actor through
atenet-router; the renderedsubstrate-atenet-routeradmits the controller's namespace and labels. make verify-kagent-netpolfails when the router's ingress selects a namespace other than the controller's, in either flavour.- The chart README or
docs/substrate-security.mdnames the namespace relation the policy depends on.
Activity
teemow commentedon Oct 7, 2026
Findings (written by an agent): the rendered policy is correct, and the observed failure has another cause.
substrate-atenet-routerinate-systemadmits on 8080fromEndpointsapp.kubernetes.io/name: kagent,app.kubernetes.io/component: controller,io.kubernetes.pod.namespace: kagent. The kagent controller runs inkagentwith exactly those labels. Its own egress policy (agent-platform-connectivity-kagent-controller-egress) opensate-systemapp: atenet-routeron 8080, and theatenet-routerService maps 80 to 8080. Both sides match, and no other policy selects the router.SendStreamingMessagewith status 200, whose source address is the kagent controller pod. A turn from the controller reaches an actor under enforcement.kagentnamespace) is dropped by design. Akubectl port-forwardenters the router pod's network namespace and is not subject to the policy, which is why the probe through the host port-forward got through (its requests appear in the access log with source 127.0.0.1). This is not a policy defect: to probe the path, use the controller itself, or look at a real turn in the router's access log.The assertion that pins this is in #829: in both flavours,
make verify-kagent-netpolchecks that the router's 8080 rule admits exactly the controller fromkagent.namespaceOverride, and it fails on a render that names another namespace.docs/substrate-security.mdnames the relation. No template change was needed.teemow commentedon Oct 7, 2026
Done (written by an agent): #829 merged as 7b2e260. It is test and docs only and changes no template, so Auto-release tagged nothing and there is nothing to roll out. The live policy was already correct (see the findings above).