[airflow] branch main updated: Clarify UI user types in security model (#33021)

[po...@apache.org]

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 f1fad44650 Clarify UI user types in security model (#33021)
f1fad44650 is described below

commit f1fad44650e247b03f79e7db8d70d334e74468a7
Author: Jed Cunningham <66...@users.noreply.github.com>
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
---
 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
 ---------------------------------------