This is an automated email from the ASF dual-hosted git repository. ephraimanierobi pushed a commit to branch v2-7-test in repository https://gitbox.apache.org/repos/asf/airflow.git
commit 5ae23ebe1c440103a7f65563933dd258c7f207c8 Author: Jed Cunningham <[email protected]> AuthorDate: Sun Aug 13 12:06:28 2023 -0600 Clarify UI user types in security model (#33021) * Clarify op users in security model * Switch the order around (cherry picked from commit f1fad44650e247b03f79e7db8d70d334e74468a7) --- docs/apache-airflow/security/access-control.rst | 19 +++++--------- docs/apache-airflow/security/security_model.rst | 34 ++++++++++++------------- 2 files changed, 22 insertions(+), 31 deletions(-) diff --git a/docs/apache-airflow/security/access-control.rst b/docs/apache-airflow/security/access-control.rst index e7543d1966..0ac191f6f8 100644 --- a/docs/apache-airflow/security/access-control.rst +++ b/docs/apache-airflow/security/access-control.rst @@ -34,9 +34,9 @@ regarding its security model. Default Roles ''''''''''''' Airflow ships with a set of roles by default: Admin, User, Op, Viewer, and Public. -Only ``Admin`` users could configure/alter the permissions for other roles. But it is not recommended -that ``Admin`` users alter these default roles in any way by removing -or adding permissions to these roles. +By default, only ``Admin`` users can configure/alter permissions for roles. However, +it is recommended that these default roles remain unaltered, and instead ``Admin`` users +create new roles with the desired permissions if changes are necessary. Admin ^^^^^ @@ -49,38 +49,31 @@ Public Viewer ^^^^^^ -``Viewer`` users have limited viewer permissions +``Viewer`` users have limited read permissions: .. exampleinclude:: /../../airflow/www/security.py :language: python :start-after: [START security_viewer_perms] :end-before: [END security_viewer_perms] -on limited web views. - User ^^^^ -``User`` users have ``Viewer`` permissions plus additional user permissions +``User`` users have ``Viewer`` permissions plus additional permissions: .. exampleinclude:: /../../airflow/www/security.py :language: python :start-after: [START security_user_perms] :end-before: [END security_user_perms] -on User web views which is the same as Viewer web views. - Op ^^ -``Op`` users have ``User`` permissions plus additional op permissions +``Op`` users have ``User`` permissions plus additional permissions: .. exampleinclude:: /../../airflow/www/security.py :language: python :start-after: [START security_op_perms] :end-before: [END security_op_perms] -on ``User`` web views. - - Custom Roles ''''''''''''' diff --git a/docs/apache-airflow/security/security_model.rst b/docs/apache-airflow/security/security_model.rst index 05c87222cc..addb69e882 100644 --- a/docs/apache-airflow/security/security_model.rst +++ b/docs/apache-airflow/security/security_model.rst @@ -46,11 +46,8 @@ varying access and capabilities: that DAG code uses to access external systems. DAG Authors have full access to the metadata database and internal audit logs. -3. **Authenticated UI users**: They have access to the UI and API. Admin - users can manage permissions and execute code on workers. Connection - configuration users can configure connections and execute code on - workers. Operations users have access to DAG execution status. Trust - is crucial to prevent abuse and Denial of Service attacks. +3. **Authenticated UI users**: They have access to the UI and API. See below + for more details on the capabilities authenticated UI users may have. 4. **Non-authenticated UI users**: Airflow doesn't support unauthenticated users by default. If allowed, potential vulnerabilities @@ -60,7 +57,11 @@ Capabilities of authenticated UI users -------------------------------------- The capabilities of **Authenticated UI users** can vary depending on -what roles have been configured by the Deployment Manager or Admin users as well as what permissions those roles have. Permissions on roles can be scoped as tightly as a single DAG, for example, or as broad as Admin. Below are three general categories to help conceptualize some of the capabilities authenticated users may have: +what roles have been configured by the Deployment Manager or Admin users +as well as what permissions those roles have. Permissions on roles can be +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 @@ -72,7 +73,11 @@ what roles have been configured by the Deployment Manager or Admin users as well They also have the ability to create a Webserver Denial of Service situation and should be trusted not to misuse this capability. -2. **Connection configuration users**: They configure connections and +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. @@ -81,17 +86,10 @@ what roles have been configured by the Deployment Manager or Admin users as well create a Webserver Denial of Service situation and should be trusted not to misuse this capability. -3. **Operations users**: They have access to DAG execution status via - the UI. Currently, Airflow lacks full protection for accessing groups - of DAGs' history and execution. They can perform actions such as - clearing, re-running, triggering DAGs, and changing parameters. - Depending on access restrictions, they may also have access to - editing variables and viewing Airflow configuration. They should not - have access to sensitive system-level information or connections, and - they should not be able to access sensitive task information unless - deliberately exposed in logs by DAG authors. They should be trusted - not to abuse their privileges, as they can potentially overload the - server and cause Denial of Service situations. +4. **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. + +For more information on the capabilities of authenticated UI users, see :doc:`/security/access-control`. Responsibilities of Deployment Managers ---------------------------------------
