This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new 2d200ecfb75 docs(security): clarify Task Execution API coverage in
DAG-author-isolation chapter (#66194)
2d200ecfb75 is described below
commit 2d200ecfb75a05a2f1529bc048f182a3cce06d1e
Author: Jarek Potiuk <[email protected]>
AuthorDate: Mon May 4 01:43:17 2026 +0200
docs(security): clarify Task Execution API coverage in DAG-author-isolation
chapter (#66194)
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.
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
---
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,
