ADORSYS-GIS / ADORSYS-GIS/converse-frontends
[Ticket]: Console proxy dials public ingress for in-cluster services
- Ngôn ngữ chính
- TypeScript
- Star
- 0
- Fork
- 0
- Merge trung bình
- 1 giờ 49 phút
- Pull request đã merge (30 ngày)
- 253
Mô tả
## Type
Technical debt / architecture
## Summary
The console's server-side proxy dials `https://self-service.ai.camer.digital` — a **public** ingress — for `backendUrl`, `budgetUrl` and `usageUrl`, even though it runs in the `converse` namespace alongside `lightbridge-api`, `lightbridge-budget`, `lightbridge-idp` and `lightbridge-usage`.
Expected result:
> Server-to-server traffic stays inside the cluster instead of hairpinning out through public DNS, TLS and the ingress and back in.
## Intent
These values were **inherited, not chosen**. `environments/prod/values/console-ui.yaml` says so in its own comments:
> `backendUrl / apiBasePath`: **SAME host + RPC prefix converse-ui.yaml uses** (`EXPO_PUBLIC_BACKEND_URL` / `EXPO_PUBLIC_API_BASE_PATH`)
> `usageUrl`: **same host as `EXPO_PUBLIC_USAGE_URL`**, for feature parity with self-service's usage dashboard
`converse-ui` is the Expo app: a **browser** client, which had no alternative, because a browser cannot resolve `*.converse.svc`. The console is architecturally different — ADR 0009 Decision 3 makes its Next server the only exposed origin and has it proxy every backend server-side. That constraint does not transfer, and copying the values carried it across anyway.
Nothing is broken today for the rpc/budget legs; this is about the shape being accidental rather than intended.
## Source of truth (links)
- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/docs/adr/0009-nextjs-console-replacement.md (Decision 3 — server-side proxy, no backend exposed to the browser)
- `ai-helm-values` `environments/prod/values/console-ui.yaml` (the inheritance comments quoted above)
- `ai-helm-values` `environments/prod/values/lightbridge-app.yaml` (`usage_service.base_url` already uses the in-cluster form)
## Current Behavior
Each RPC from the console leaves the pod, exits the cluster, resolves public DNS, terminates TLS at Traefik, passes a `StripPrefix` middleware that removes `/api/v2`, and re-enters the cluster to reach `lightbridge-api` — which serves the unprefixed `/rpc/{op}` directly.
That path depends on public DNS, the ingress, the public certificate and a prefix-stripping middleware **for traffic between two pods in the same namespace**. Any of them degrading takes the console down while both services are perfectly healthy.
Note `lightbridge-app.yaml` already does the opposite for its own dependency: `usage_service.base_url: "https://lightbridge-usage.converse.svc:3006"`. The in-cluster convention exists; the console just isn't following it.
## Expected Behavior
`backendUrl`, `budgetUrl` and `usageUrl` point at in-cluster service URLs. Consequences worth stating:
- `apiBasePath` can likely return to `/` — console-ui.yaml's own comment says that default "only applies when backendUrl points directly at authz-api with no gateway in front", which is exactly what this change creates.
- The `StripPrefix` middleware stops being on the console's critical path.
- Public ingress remains for the **browser**-facing origin (`console.ai.camer.digital`), which is unaffected.
## Acceptance Criteria
- [ ] Each leg is verified individually: in-cluster service name, port, and whether that listener requires client certificates.
- [ ] `apiBasePath` is re-derived rather than assumed.
- [ ] A leg is only repointed once proven reachable — no big-bang switch of all three.
- [ ] The public origin for browser traffic is untouched.
## Out of Scope
- The usage leg's mTLS work (#275) — a prerequisite for that leg, being built separately.
## Open question — must be answered before implementing
**Do `lightbridge-api` and `lightbridge-budget` require client certificates on their in-cluster ports?** The usage query listener on 3006 demonstrably does (`insecure_skip_verify: false`, `client_cert_path`). Whether the other two do is **not verified** — the `tls:` blocks in `lightbridge-app.yaml` were not traced to a conclusion. If they do, this ticket depends on #275's dispatcher generalising beyond the usage leg, which would be an argument for building it that way rather than usage-only.
## Technical Context
`apps/console/src/server/{env,proxy-target}.ts`, `ai-helm-values` `environments/prod/values/console-ui.yaml`.
## Human accountable owner
@stephane-segning
## AI Usage Declaration
Raised from the owner's question "why use self-service.ai.camer.digital and not the in-cluster svc url?". The inheritance explanation is quoted from the values file's own comments; the mTLS status of the api/budget legs is explicitly flagged as unverified rather than assumed either way.
Hướng dẫn đóng góp
Đánh giá
Issue này chưa được đánh giá.