This is an automated email from the ASF dual-hosted git repository.
eladkal pushed a commit to branch v3-2-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/v3-2-test by this push:
new afd9a20919d [v3-2-test] docs(security): clarify Task Execution API
coverage in DAG-author-isolation chapter (#66194) (#66322)
afd9a20919d is described below
commit afd9a20919d2fe408b22cc4d21353c45ba5c6971
Author: github-actions[bot]
<41898282+github-actions[bot]@users.noreply.github.com>
AuthorDate: Tue May 5 16:30:59 2026 +0300
[v3-2-test] docs(security): clarify Task Execution API coverage in
DAG-author-isolation chapter (#66194) (#66322)
Add an explicit paragraph to the "Limiting Dag Author access to subset
of Dags" chapter making clear it covers the Task Execution API used by
the Task SDK, not only the UI / public REST API.
The existing chapter already states that "regardless of execution
context, Dag authors have access to all Dags" and that "workloads from
different teams still share the same Execution API". Readers nonetheless
ask whether the Execution JWT enforces per-Dag authorization. The new
paragraph answers that explicitly: it does not, and `ti:self` is not a
per-Dag access control.
(cherry picked from commit 2d200ecfb75a05a2f1529bc048f182a3cce06d1e)
Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https:
//github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions
Co-authored-by: Jarek Potiuk <[email protected]>
---
airflow-core/docs/security/security_model.rst | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/airflow-core/docs/security/security_model.rst
b/airflow-core/docs/security/security_model.rst
index 96f6f66783b..46bf7ab8b62 100644
--- a/airflow-core/docs/security/security_model.rst
+++ b/airflow-core/docs/security/security_model.rst
@@ -218,6 +218,13 @@ have access to all Dags in the Airflow installation and
they can
modify any of those Dags - no matter which Dag the task code is executed for.
This means that Dag authors can
modify state of any task instance of any Dag, and there are no finer-grained
access controls to limit that access.
+This applies to every interface a Dag author's code can reach — including the
Task Execution API
+that workers use via the Task SDK. The Execution JWT issued to a running task
does **not** carry
+per-Dag authorization: a task holding a valid token can call state-mutating
Execution API endpoints
+(triggering Dag runs, clearing Dag runs, reading or writing variables,
connections and XComs, etc.)
+for **any** Dag in the installation. The ``ti:self`` token scope restricts
cross-task-instance state
+mutation only; it is not a per-Dag access control.
+
There is an **experimental** multi-team feature in Airflow (``[core]
multi_team``) that provides UI-level and
REST API-level RBAC isolation between teams. However, this feature **does not
yet guarantee task-level isolation**.
At the task execution level, workloads from different teams still share the
same Execution API, signing keys,
