potiuk opened a new pull request, #64760:
URL: https://github.com/apache/airflow/pull/64760
Add comprehensive documentation for JWT token authentication and strengthen
the security model
documentation to be precise, unambiguous, and aligned with the security
team's policies.
## Changes
**New document: `airflow-core/docs/security/jwt_token_authentication.rst`**
- Detailed technical reference for JWT authentication in both REST API and
Execution API
- Token structure, claims, signing modes (symmetric/asymmetric), JWKS support
- Token lifecycle: acquisition, validation, refresh, revocation (REST API
only)
- Execution API token flow: generation by executor, delivery to workers,
`ti:self` enforcement
- DFP/Triggerer in-process bypass documentation
- Worker memory protection via `PR_SET_DUMPABLE`
- Workload isolation limitations and multi-team caveats
- Complete configuration reference with defaults and timings
**Updated: `airflow-core/docs/security/security_model.rst`**
- Precise language about database access: workers don't have it,
DFP/Triggerer do
- New section "JWT authentication and workload isolation" with current
isolation limitations
- New section "Deployment hardening for improved isolation" with actionable
guidance
- New section "What is NOT considered a security vulnerability" covering all
categories
from the security team's canned response policies:
- DAG author arbitrary code execution
- Unsanitized input in operators/hooks
- DFP/Triggerer database access
- Shared Execution API resources
- Connection configuration capabilities
- DoS/self-XSS by authenticated users
- Simple Auth Manager issues
- Docker image scan results
- Automated scanner reports without human verification
- Multi-team feature clearly marked as experimental with no task-level
isolation guarantee
- Added ref labels for cross-referencing
**Fixed contradictions across documentation:**
- `configurations-ref.rst` / `set-config.rst`: Removed "use same config
across all components"
recommendation, replaced with per-component security guidance
- `production-deployment.rst`: Same fix
- `upgrading_to_airflow3.rst`: "ensures isolation" → "improves isolation"
with DFP/Triggerer caveat
- `best-practices.rst`: "Complete isolation" → "Strong process-level
isolation" for KPO
- `public-airflow-interface.rst`: "task code" → "worker task code" for DB
access restriction
- `multi-team.rst`: Added "(at the UI and API level)" caveat to resource
isolation use case
- `config.yml`: Updated `jwt_secret` description with security guidance
**Updated: `AGENTS.md`**
- Architecture Boundaries: DFP/Triggerer explicitly documented as having DB
access and bypassing JWT
- New Security Model section listing intentional design choices vs actual
vulnerabilities
- Full "NOT vulnerabilities" list for AI agents performing security analysis
**Updated: `.github/instructions/code-review.instructions.md`**
- Clarified DFP/Triggerer "isolation" — they have DB access and bypass JWT
by design
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Claude Opus 4.6)
Generated-by: Claude Code (Claude Opus 4.6) following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
