Summary
Both API and dashboard share a single global API_KEY.
This makes it very insecure since this single key that can start runs also allows to read full DAG and logs data that otherwise would be expected to be private. Agents also need to share the same key for communicating with each other. A compromise of any agent deployed on different machines means it now has wide access to all data.
Alternatives are to use external WAF access rules or 3rd-party reverse proxies just to be able to gate access using multiple keys to avoid exposing/sharing the global key.
Proposed solution
Add the ability for multiple virtual keys that can be scoped to exact routes and access. Keep only the admin token that is needed for client-side admin auth inside the UI.
- UI access
- Runs
- Queue
- Logs
- Input
- Output
- Triggers
- Playground
- API access
- Control executions: start, stop, pause
- Fetch logs
- Fetch DAG and specific fields
- Readonly flavors
Alternatives considered
Cloud load balancing with multiple matching rules and manual key generation and hashing.
Additional context
Summary
Both API and dashboard share a single global API_KEY.
This makes it very insecure since this single key that can start runs also allows to read full DAG and logs data that otherwise would be expected to be private. Agents also need to share the same key for communicating with each other. A compromise of any agent deployed on different machines means it now has wide access to all data.
Alternatives are to use external WAF access rules or 3rd-party reverse proxies just to be able to gate access using multiple keys to avoid exposing/sharing the global key.
Proposed solution
Add the ability for multiple virtual keys that can be scoped to exact routes and access. Keep only the admin token that is needed for client-side admin auth inside the UI.
Alternatives considered
Cloud load balancing with multiple matching rules and manual key generation and hashing.
Additional context