Summary
The atenet router's /statusz page (--status-port, default 4040) has a "Router Service IP" panel that tries to get the atenet-router Service via the Kubernetes API — but the RBAC the installer ships for the router's ServiceAccount never grants access to Services. The panel therefore renders a raw forbidden error on every install:
Router Service IP
Lookup Failed: services "atenet-router" is forbidden: User "system:serviceaccount:ate-system:atenet-router"
cannot get resource "services" in API group "" in the namespace "ate-system"
Verification (live install, substrate rev 0d85e85 on GKE)
The ServiceAccount's only binding is the endpointslices role:
$ kubectl auth can-i get services -n ate-system --as=system:serviceaccount:ate-system:atenet-router
no
$ kubectl get role atenet-router-endpointslices -n ate-system -o jsonpath='{.rules}'
[{"apiGroups":["discovery.k8s.io"],"resources":["endpointslices"],"verbs":["get","watch","list"]}]
So the statusz code (cmd/atenet/internal/router/status.go) calls an API that its own deployment manifests forbid — the panel is dead on arrival, not a cluster-specific misconfiguration.
Everything else on the page works
For context, the rest of /statusz renders fine and is genuinely useful (build rev, port allocation, request-parking state, dataplane / Kubernetes API / ATE API health checks with counters, full CLI args and resolved flags). This is only about the Service IP panel.
Suggested fix (either)
- Add
services get (scoped to the router's namespace, arguably even resourceNames: [atenet-router]) to the atenet-router-endpointslices role — or a small dedicated role, since the existing one is named for endpointslices; or
- Drop the API lookup: the page already knows the namespace, and the Service IP could be injected via env/downward-API-adjacent means at deploy time, avoiding the extra RBAC surface for a display-only field.
Option 2 keeps the router's RBAC minimal, which the current single-purpose role suggests was the intent.
Summary
The atenet router's
/statuszpage (--status-port, default 4040) has a "Router Service IP" panel that tries togettheatenet-routerService via the Kubernetes API — but the RBAC the installer ships for the router's ServiceAccount never grants access to Services. The panel therefore renders a raw forbidden error on every install:Verification (live install, substrate rev 0d85e85 on GKE)
The ServiceAccount's only binding is the endpointslices role:
So the statusz code (
cmd/atenet/internal/router/status.go) calls an API that its own deployment manifests forbid — the panel is dead on arrival, not a cluster-specific misconfiguration.Everything else on the page works
For context, the rest of
/statuszrenders fine and is genuinely useful (build rev, port allocation, request-parking state, dataplane / Kubernetes API / ATE API health checks with counters, full CLI args and resolved flags). This is only about the Service IP panel.Suggested fix (either)
servicesget(scoped to the router's namespace, arguably evenresourceNames: [atenet-router]) to theatenet-router-endpointslicesrole — or a small dedicated role, since the existing one is named for endpointslices; orOption 2 keeps the router's RBAC minimal, which the current single-purpose role suggests was the intent.