pankajkoti commented on code in PR #36022: URL: https://github.com/apache/airflow/pull/36022#discussion_r1413427589
########## docs/apache-airflow/security/security_model.rst: ########## @@ -67,40 +81,134 @@ scoped as tightly as a single DAG, for example, or as broad as Admin. Below are four general categories to help conceptualize some of the capabilities authenticated users may have: -1. **Admin users**: They manage and grant permissions to other users, - with full access to all UI capabilities. They can potentially execute - code on workers by configuring connections and need to be trusted not - to abuse these privileges. They have access to sensitive credentials - and can modify them. By default, they don't have access to - system-level configuration. They should be trusted not to misuse - sensitive information accessible through connection configuration. - They also have the ability to create a Webserver Denial of Service - situation and should be trusted not to misuse this capability. - -2. **Operations users**: The primary difference between an operator and admin - if the ability to manage and grant permissions to other users - only admins - are able to do this. Otherwise assume they have the same access as an admin. - -3. **Connection configuration users**: They configure connections and - potentially execute code on workers during DAG execution. Trust is - required to prevent misuse of these privileges. They have full access - to sensitive credentials stored in connections and can modify them. - Access to sensitive information through connection configuration - should be trusted not to be abused. They also have the ability to - create a Webserver Denial of Service situation and should be trusted - not to misuse this capability. - -4. **Audit log users**: They can view audit events for the whole Airflow installation. - -5. **Normal Users**: They can view and interact with the UI and API. - They are able to view and edit DAGs, task instances, and DAG runs, and view task logs. +Admin users +........... + +They manage and grant permissions to other users, +with full access to all UI capabilities. They can potentially execute +code on workers by configuring connections and need to be trusted not +to abuse these privileges. They have access to sensitive credentials +and can modify them. By default, they don't have access to +system-level configuration. They should be trusted not to misuse +sensitive information accessible through connection configuration. +They also have the ability to create a Webserver Denial of Service +situation and should be trusted not to misuse this capability. + +Operations users +................ + +The primary difference between an operator and admin if the ability to manage and grant permissions +to other users - only admins are able to do this. Otherwise assume they have the same access as an admin. + +Connection configuration users +.............................. + +They configure connections and potentially execute code on workers during DAG execution. Trust is +required to prevent misuse of these privileges. They have full access +to sensitive credentials stored in connections and can modify them. +Access to sensitive information through connection configuration +should be trusted not to be abused. They also have the ability to +create a Webserver Denial of Service situation and should be trusted +not to misuse this capability. + +Audit log users +............... + +They can view audit events for the whole Airflow installation. + +Regular users +............. + +They can view and interact with the UI and API. They are able to view and edit DAGs, +task instances, and DAG runs, and view task logs. For more information on the capabilities of authenticated UI users, see :doc:`/security/access-control`. +Capabilities of DAG Authors +--------------------------- + +DAG authors are able to submit code - via Python files placed in the DAGS_FOLDER - that will be executed +in a number of circumstances. The code to execute is neither verified, checked nor sand-boxed by Airflow +(that would be very difficult if not impossible to do), so effectively DAG authors can execute arbitrary +code on the workers (part of Celery Workers for Celery Executor, local processes run by scheduler in case +of Local Executor, Task Kubernetes POD in case of Kubernetes Executor), in the DAG File Processor +(which can be either executed as standalone process or can be part of the Scheduler) and in the Triggerer. + +There are several consequences of this model chosen by Airflow, that deployment managers need to be aware of: + +Local executor and built-in DAG File Processor +.............................................. + +In case of Local Executor and DAG File Processor running as part of the Scheduler, DAG authors can execute +arbitrary code on the machine where scheduler is running. This means that they can affect the scheduler +process itself, and potentially affect the whole Airflow installation - including modifying cluster-wide +policies and changing Airflow configuration. If you are running Airflow with one of those settings, +the Deployment Manager must trust the DAG authors not to abuse this capability. + +Celery Executor +............... + +n case of Celery Executor, DAG authors can execute arbitrary code on the Celery Workers. This means that Review Comment: ```suggestion In case of Celery Executor, DAG authors can execute arbitrary code on the Celery Workers. This means that ``` ########## docs/apache-airflow/security/security_model.rst: ########## @@ -67,40 +81,134 @@ scoped as tightly as a single DAG, for example, or as broad as Admin. Below are four general categories to help conceptualize some of the capabilities authenticated users may have: -1. **Admin users**: They manage and grant permissions to other users, - with full access to all UI capabilities. They can potentially execute - code on workers by configuring connections and need to be trusted not - to abuse these privileges. They have access to sensitive credentials - and can modify them. By default, they don't have access to - system-level configuration. They should be trusted not to misuse - sensitive information accessible through connection configuration. - They also have the ability to create a Webserver Denial of Service - situation and should be trusted not to misuse this capability. - -2. **Operations users**: The primary difference between an operator and admin - if the ability to manage and grant permissions to other users - only admins - are able to do this. Otherwise assume they have the same access as an admin. - -3. **Connection configuration users**: They configure connections and - potentially execute code on workers during DAG execution. Trust is - required to prevent misuse of these privileges. They have full access - to sensitive credentials stored in connections and can modify them. - Access to sensitive information through connection configuration - should be trusted not to be abused. They also have the ability to - create a Webserver Denial of Service situation and should be trusted - not to misuse this capability. - -4. **Audit log users**: They can view audit events for the whole Airflow installation. - -5. **Normal Users**: They can view and interact with the UI and API. - They are able to view and edit DAGs, task instances, and DAG runs, and view task logs. +Admin users +........... + +They manage and grant permissions to other users, +with full access to all UI capabilities. They can potentially execute +code on workers by configuring connections and need to be trusted not +to abuse these privileges. They have access to sensitive credentials +and can modify them. By default, they don't have access to +system-level configuration. They should be trusted not to misuse +sensitive information accessible through connection configuration. +They also have the ability to create a Webserver Denial of Service +situation and should be trusted not to misuse this capability. + +Operations users +................ + +The primary difference between an operator and admin if the ability to manage and grant permissions Review Comment: ```suggestion The primary difference between an operator and admin is the ability to manage and grant permissions ``` -- 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: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
