GitHub user bobbai00 added a comment to the discussion: Improvement: Treat
TexeraAgents as access-controlled Resources, just like other resources
(workflows, datasets and computing units)
### Authentication foundation + per-deployment-mode setup
Splitting agent access control into two layers makes the rollout incremental:
- **Authentication** — verify the JWT and put the agent-service behind the
gateway's ext-authz (the access-control-service), instead of the agent-service
decoding tokens itself. Tracked in #5561.
- **Authorization (per-agent ownership)** — this discussion. Until the
persistence + owner model here lands, authz is intentionally **allow-all**: any
authenticated `REGULAR`/`ADMIN` user may reach any agent. The
access-control-service is where the per-agent decision will live once agents
have an owner (uid).
The authentication layer is a **gateway** concern, so it's wired up differently
in each deployment mode:
**Kubernetes (Envoy Gateway)** — canonical path, mirroring how computing-unit /
executions / pve are already authorized:
- An Envoy `SecurityPolicy` (`extAuth.http` → `access-control-service
/api/auth`) targeting the `*-agent-service-route` HTTPRoute.
- A branch in `AccessControlResource.authorize()` for `/api/agents…` that runs
`JwtParser.parseToken` + `SessionUser.isRoleOf(REGULAR/ADMIN)` and returns the
trusted `x-user-*` headers on success (401/403 otherwise).
**Docker Compose (single-node, nginx)** — nginx is the gateway, so use its
ext-authz equivalent, `auth_request`. Sketch:
```nginx
location /api/agents {
auth_request /_agent_auth;
proxy_pass http://agent-service:3001;
# ...existing ws-upgrade headers...
}
location = /_agent_auth {
internal;
# $request_uri makes access-control see /api/auth/api/agents/... — same
shape Envoy produces,
# so the SAME authorize() branch handles both gateways.
proxy_pass http://access-control-service:9096/api/auth$request_uri;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
}
```
The `Authorization: Bearer` header is forwarded automatically, and the `/react`
WebSocket carries its token as `?access-token=…` (part of `$request_uri`), so
no `authorize()` changes are needed beyond the new `/api/agents` branch.
**Bare-metal dev (Angular `ng serve` + `proxy.config.json`)** — the dev proxy
is not a real gateway and can't do ext-authz subrequests. This is already the
case for the *other* protected routes: in `proxy.config.json`, `/wsapi` and
`/pve` point straight at the services (`:8085`), bypassing access-control
entirely. So for parity, `/api/agents` stays direct-to-`:3001` in dev with **no
ext-authz** — enforcement is exercised through the docker-compose or k8s
gateways. (To test the auth path locally, point the dev proxy's `/api/agents`
at the docker-compose nginx instead of `:3001`.)
**Frontend (all modes):** attach the JWT to every agent call — `Authorization:
Bearer` on REST (today `agentHeaders()` only sets `X-Agent-Workflow-Id` and
`fetchModelTypes()` sends nothing) and `?access-token=…` on the `/react` WS —
then drop the agent-service's home-grown `decodeJWT` / `validateToken` and have
it trust the gateway-injected `x-user-*` headers (which only exist after
ext-authz passes).
Net: ship authentication now (allow-all authz), and this discussion's ownership
model becomes the per-agent authorization step layered on top.
GitHub link:
https://github.com/apache/texera/discussions/5302#discussioncomment-17215412
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
