2.0 KiB
2.0 KiB
7.1 — /cluster/* proxies to atlas (GREEN)
Phase: 7 — Additional capability prefixes Stage: GREEN Depends on: Phase 6 (cutover) — done, confirmed live in-cluster
atlas lives in a separate repo, riotpiao-backend. It keeps its own informers and its
own RBAC. The gateway proxies to it and holds no Kubernetes credentials of its own —
this is G2, and it is the whole reason cluster-read capability lives behind atlas
rather than in the edge process.
/cluster/*onapi.riotpiao.comproxies to the atlas Service- The gateway gains no ServiceAccount token, no kubeconfig and no RBAC as part of this. Any authorization decision about cluster data is atlas's, not the gateway's (G2)
- Path rewriting between the
/clusterprefix and atlas's own paths is explicit in configuration - Connect, read and write timeouts and a body cap are explicit for this route, with no silent defaults (G6)
- The route requires authentication, and the token is checked for cluster capability — a token minted for queue access must not read cluster state
- The NetworkPolicy is extended to allow egress to atlas and nothing more
/v1/*behaviour is byte-identical before and after this route is added — the prefixes cannot collide- Metrics and rejection counters cover this route with its own route label
Verify
curl -s -o /dev/null -w '%{http_code}\n' https://api.riotpiao.com/cluster/healthz
# expected: 401 without a token
curl -s -H "authorization: Bearer $CLUSTER_TOKEN" https://api.riotpiao.com/cluster/healthz
# expected: atlas's own response body, proxied unmodified
curl -s -o /dev/null -w '%{http_code}\n' -H "authorization: Bearer $QUEUE_ONLY_TOKEN" \
https://api.riotpiao.com/cluster/healthz
# expected: 403 — a queue token does not grant cluster capability
kubectl -n api get pod -l app=homelab-frontend -o jsonpath='{.items[0].spec.serviceAccountName}{"\n"}'
# expected: a ServiceAccount with no RBAC bindings; the gateway still holds no cluster credentials