fix: workflow scheduler now applies route-level security controls

[ionfwsrijan]

Description

Fixes #655 — Workflow Scheduler Bypasses All Route-Level Security Controls.

Changes

1. routes.py — Extracted _execute_scan_safe() shared function that applies consent validation, safe mode enforcement, target validation, rate limiting, and concurrency limits. Both start_task() and run_workflow_once() now use this entry point.

2. workflows.py — Refactored _run_workflow() to apply all security checks directly: plugin existence validation, target validation (safe mode + timeout), network policy enforcement, rate limiting per client+plugin, concurrency slot acquisition, and source-tagged audit logging. Each check failure gracefully skips the step instead of crashing the scheduler loop.

3. ratelimit.py — Added WorkflowRateLimiter class with two methods:

   • check_workflow_rate_limit(workflow_id, min_interval) — prevents a single workflow from firing faster than the configured minimum interval
   • check_user_workflow_limit(user_id, max_workflows) — limits the number of workflows a single user can create

4. executor.py — Added source parameter to create_task() and included "source": "api" | "workflow" | "scheduler" in audit log context for all task lifecycle events.

5. config.py — Added workflow configuration settings:

   • max_workflows_per_user (default 50)
   • workflow_min_interval_seconds (default 60)
   • workflow_consent_refresh_days (default 30)

Impact

• Rate limit bypass: ✅ Closed — scheduler now checks rate limits per (client, plugin) pair
• Audit invisibility: ✅ Closed — all executions tagged with source in audit log
• Access revocation bypass: ✅ Partially mitigated — consent re-validation required each run
• Consent bypass: ✅ Closed — scheduler respects require_consent setting

[utksh1]

This needs changes before review can proceed. The branch currently has merge conflicts, and the new _execute_scan_safe() path schedules executor.execute_task() internally while start_task() also adds executor.execute_task() to BackgroundTasks, so API-created scans can be executed twice. Please rebase on current main, resolve conflicts, and make task scheduling happen in exactly one place while preserving the existing TestClient/background task behavior.

[ionfwsrijan]

@utksh1 I've address the requested changes. You may review it now

[utksh1]

Re-reviewed the latest push. This route-level scheduler security change is still too broad to merge without a clean rebase and focused tests for the workflow scheduler path. Please reduce unrelated churn, rebase on main, and demonstrate the route-level controls are applied consistently.

[ionfwsrijan]

Rebased on latest main. Scope reduced to 7 backend files + focused tests. No unrelated docs, frontend, or test deletions. Single clean commit. See diff for details.

[ionfwsrijan]

@utksh1 I've made the changes you may review now.

[utksh1]

Checks are green, but this is still too broad for the workflow scheduler security issue. The PR rewrites a large part of routes.py, changes executor audit/completion behavior, adds a new global workflow rate limiter, changes main.py shutdown behavior, and modifies plugin input handling. Please split this down to the minimum scheduler hardening path: validate/enforce policy for scheduler-triggered workflow scans with focused tests, and move unrelated executor lifecycle, shutdown, and route refactors into separate PRs.

[ionfwsrijan]

@utksh1 I've addressed the changes asked. Please review it.

[utksh1]

Approved current head after re-review. The latest update narrows the PR to scheduler workflow security controls, removes the unrelated route/executor/shutdown/plugin-input refactors from the earlier version, and keeps focused coverage for workflow rate limiting, target validation, task rate limiting, safe-mode handling, and concurrency acquisition. I also updated the branch onto current main; fresh CI is green.

[ionfwsrijan]

@utksh1 Thanks for your valuable time. Please review my other PRs too.