potiuk commented on code in PR #64760:
URL: https://github.com/apache/airflow/pull/64760#discussion_r3044983312


##########
airflow-core/docs/security/security_model.rst:
##########
@@ -282,6 +312,309 @@ Access to all Dags
 All Dag authors have access to all Dags in the Airflow deployment. This means 
that they can view, modify,
 and update any Dag without restrictions at any time.
 
+.. _jwt-authentication-and-workload-isolation:
+
+JWT authentication and workload isolation
+-----------------------------------------
+
+Airflow uses JWT (JSON Web Token) authentication for both its public REST API 
and its internal
+Execution API. For a detailed description of the JWT authentication flows, 
token structure, and
+configuration, see :doc:`/security/jwt_token_authentication`.
+
+Current isolation limitations
+.............................
+
+While Airflow 3 significantly improved the security model by preventing worker 
task code from
+directly accessing the metadata database (workers now communicate exclusively 
through the
+Execution API), **perfect isolation between Dag authors is not yet achieved**. 
Dag author code
+potentially still executes with direct database access in the Dag File 
Processor and Triggerer.
+
+**Software guards vs. intentional access**
+   Airflow implements software-level guards that prevent **accidental and 
unintentional** direct database
+   access from Dag author code. The Dag File Processor removes the database 
session and connection
+   information before forking child processes that parse Dag files, and worker 
tasks use the Execution
+   API exclusively.
+
+   However, these software guards **do not protect against intentional, 
malicious access**. The child
+   processes that parse Dag files and execute trigger code run as the **same 
Unix user** as their parent
+   processes (the Dag File Processor manager and the Triggerer respectively). 
Because of how POSIX
+   process isolation works, a child process running as the same user can 
retrieve the parent's
+   credentials through several mechanisms:
+
+   * **Environment variables**: On Linux, any process can read 
``/proc/<PID>/environ`` of another
+     process running as the same user — so database credentials passed via 
environment variables
+     (e.g., ``AIRFLOW__DATABASE__SQL_ALCHEMY_CONN``) can be read from the 
parent process.

Review Comment:
   Actually - we already have approprirate "workload" document for that.



-- 
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]

Reply via email to