ADORSYS-GIS / ADORSYS-GIS/converse-frontends

[Ticket]: Console proxy dials public ingress for in-cluster services

Đang mở
#357 0 bình luận 0 reaction 0 người được giao Xem trên GitHub
ticket
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

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.