SEC-WF-003 — Protect monitoring now and add resource scoping before multi-project rollout
| Field | Value |
|---|---|
| Status | Open; source-verified |
| Architecture state | Deployed single-project legacy access; resource-scoped authorization is future |
| Severity | High |
| Affected surface | Current and historical workflow resource metrics |
| Components | sparqd/bff-api, sparqd/workflow-backend, sparqd/workflow-resource-monitoring, sparqd/platform-stacks, OpenFGA |
| Associated issue | Not opened |
Where the problem appears
In current single-project mode, compare monitoring reachability across the deployed roles. Reserve workflow/project denial testing for the OpenFGA rollout.
Concrete observed case
The BFF monitoring route validates only that a JWT exists, forwards a caller-supplied DAG name, and calls a backend that does not authenticate callers. It does not resolve the managed workflow. This matches neither a resource-scoped model nor a strong internal service boundary. However, workflow-scoped access is not a deployed promise while the frontend remains in single-project compatibility mode. History also returns the full series for browser-side windowing.
Expected condition
Authenticate the internal monitoring call and document which current legacy
roles can view workspace metrics. Before multi-project rollout, resolve the
DAG through workflow-backend and require the active view_workflow capability.
Enforce time range, pagination, and response limits at the service in either
mode.
Cause and evidence
- The BFF route explicitly documents authentication-only behavior.
- The implemented monitoring backend defines no caller authentication and receives no end-user or workflow authorization context.
- The frontend requests full history and applies its selected range locally.
- Current KCL does not deploy the API or configure its BFF URL; deployment must
not activate this route without first defining the service boundary. See
ARCH-WF-002.
Why it matters
Any authenticated role may have broader monitoring access than intended by the current workspace policy; live role evidence is still required. Once multi-project grants exist, the same route would bypass them. Large histories also create avoidable exposure and load today.
Existing controls and workarounds
Restrict monitoring route reachability and treat DAG names as non-secret. Disable Resources for roles without independently verified workflow access.
Alternatives considered
- Recommended: authenticate the service boundary now, then add a workflow-scoped monitoring facade authorized by workflow UUID as part of the OpenFGA rollout.
- Signed internal request from workflow-backend to monitoring after permission check.
- Filter only in the UI — rejected because direct calls remain possible.
Component involvement
sparqd/workflow-backendsupplies workflow resolution now and becomes the authorization boundary after OpenFGA activation.- sparqd/bff-api exposes the managed resource path.
- Monitoring service authenticates internal callers and bounds history.
Reproduction and verification
Follow WF-S010.
Resolution conditions
Close the current service-boundary portion when deployed legacy-role tests are documented, the backend is authenticated, and history is server-bounded. Keep the multi-project portion open until OpenFGA denial tests cover warm and cold metrics.
Validation and blockers
Security, BFF, workflow-backend, monitoring, and operations owners must validate.