You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2021/02/25 00:36:42 UTC
[GitHub] [airflow] jwitz opened a new pull request #14439: Updated the latest version of the "Access Control" doc with new screen shots/ content
jwitz opened a new pull request #14439:
URL: https://github.com/apache/airflow/pull/14439
I noticed that there were some sections of the Access Control doc that were difficult to follow/ duplicative, so I tidied things up with some more examples, screen shots, and clarification.
For quick reference, here are the screen shots I included (one is an existing screenshot with the size reduced):
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-806759070
Sounds good @jhtimmins , just applied your suggestions in a batch commit. Good to know about the docs tool as well!
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on a change in pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on a change in pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#discussion_r582433430
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Review comment:
I wanted to add more info here, but I personally don't know much about the Public role and how it's used in Airflow. Any suggestions for additions here?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-1048715467
Closing this out due to being vvvvvv stale
--
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-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-806018630
@jhtimmins Do these updated changes look good to you? Would be awesome to get this merged soon.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] boring-cyborg[bot] commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screen shots/ content
Posted by GitBox <gi...@apache.org>.
boring-cyborg[bot] commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-785489031
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst)
Here are some useful points:
- Pay attention to the quality of your code (flake8, pylint and type annotations). Our [pre-commits]( https://github.com/apache/airflow/blob/master/STATIC_CODE_CHECKS.rst#prerequisites-for-pre-commit-hooks) will help you with that.
- In case of a new feature add useful documentation (in docstrings or in `docs/` directory). Adding a new operator? Check this short [guide](https://github.com/apache/airflow/blob/master/docs/apache-airflow/howto/custom-operator.rst) Consider adding an example DAG that shows how users should use it.
- Consider using [Breeze environment](https://github.com/apache/airflow/blob/master/BREEZE.rst) for testing locally, itβs a heavy docker but it ships with a working Airflow and a lot of integrations.
- Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
- Please follow [ASF Code of Conduct](https://www.apache.org/foundation/policies/conduct) for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
- Be sure to read the [Airflow Coding style]( https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#coding-style-and-best-practices).
Apache Airflow is a community-driven project and together we are making it better π.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-786734322
Thank you for the comments and clarifications @jhtimmins ! Made some changes based on your edits.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jhtimmins commented on a change in pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jhtimmins commented on a change in pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#discussion_r600913735
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,116 @@ 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, Airlfow 2.0+ uses role-based access control (RBAC) to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a default set of roles:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
-'''''''''''''
+''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You can then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
-There are five default roles: Public, Viewer, User, Op, and Admin. Each one has the permissions of the preceding role, as well as additional permissions.
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG-level access.
-DAG-level permissions
-^^^^^^^^^^^^^^^^^^^^^
+DAG-level permissions differ from resource-level permissions in a few key ways:
+- Resource-based permissions apply to all DAGs, while DAG-based permissions apply only to specific DAGs.
+- DAG-based permissions control only``can_read`` and ``can_edit`` actions (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0).
+- You have to specify an existing DAG in the name of a DAG-based permission. The specific naming convention is ``DAG:<dag-name>.can_read`` or ``DAG:<dag-name>.can_edit``.
+
+For example, the following images show how you would create a role which can only write to
+``example_python_operator``. Once you create the role, the permission appears in the **List Roles** menu.
Review comment:
```suggestion
For example, the following images show how you would create a role which can only write to ``example_python_operator``. Once you create the role, the permission appears in the **List Roles** menu.
```
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,116 @@ 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, Airlfow 2.0+ uses role-based access control (RBAC) to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a default set of roles:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
-'''''''''''''
+''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You can then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Review comment:
```suggestion
You can then assign the given role to a new user using the ``airflow users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
```
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,116 @@ 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, Airlfow 2.0+ uses role-based access control (RBAC) to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a default set of roles:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
-'''''''''''''
+''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You can then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
-There are five default roles: Public, Viewer, User, Op, and Admin. Each one has the permissions of the preceding role, as well as additional permissions.
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG-level access.
-DAG-level permissions
-^^^^^^^^^^^^^^^^^^^^^
+DAG-level permissions differ from resource-level permissions in a few key ways:
+- Resource-based permissions apply to all DAGs, while DAG-based permissions apply only to specific DAGs.
+- DAG-based permissions control only``can_read`` and ``can_edit`` actions (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0).
+- You have to specify an existing DAG in the name of a DAG-based permission. The specific naming convention is ``DAG:<dag-name>.can_read`` or ``DAG:<dag-name>.can_edit``.
+
+For example, the following images show how you would create a role which can only write to
+``example_python_operator``. Once you create the role, the permission appears in the **List Roles** menu.
+
+.. image:: /img/add-role.png
+.. image:: /img/new-role.png
+
+If an endpoint for a specific DAG requires a permission based on the DAG resource (for example, ``DAGs.can_create``),
+a role will have access if it has either the resource-based permission or a DAG-based permission.
Review comment:
```suggestion
If an endpoint for a specific DAG requires a permission based on the DAG resource (for example, ``DAGs.can_create``), a role will have access if it has either the resource-based permission or a DAG-based permission.
```
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,116 @@ 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, Airlfow 2.0+ uses role-based access control (RBAC) to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a default set of roles:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
-'''''''''''''
+''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You can then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
-There are five default roles: Public, Viewer, User, Op, and Admin. Each one has the permissions of the preceding role, as well as additional permissions.
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG-level access.
-DAG-level permissions
-^^^^^^^^^^^^^^^^^^^^^
+DAG-level permissions differ from resource-level permissions in a few key ways:
+- Resource-based permissions apply to all DAGs, while DAG-based permissions apply only to specific DAGs.
+- DAG-based permissions control only``can_read`` and ``can_edit`` actions (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0).
+- You have to specify an existing DAG in the name of a DAG-based permission. The specific naming convention is ``DAG:<dag-name>.can_read`` or ``DAG:<dag-name>.can_edit``.
+
+For example, the following images show how you would create a role which can only write to
+``example_python_operator``. Once you create the role, the permission appears in the **List Roles** menu.
+
+.. image:: /img/add-role.png
+.. image:: /img/new-role.png
+
+If an endpoint for a specific DAG requires a permission based on the DAG resource (for example, ``DAGs.can_create``),
+a role will have access if it has either the resource-based permission or a DAG-based permission.
+
+For example, if an endpoint for the ``example_python_operator`` DAG requires the resource-based ``DAGS.can_read`` permission,
+a role with the DAG-based permission ``DAG:example_python_operator.can_read`` can still access that endpoint even without ``DAGS.can_read``.
Review comment:
```suggestion
For example, if an endpoint for the ``example_python_operator`` DAG requires the resource-based ``DAGS.can_read`` permission, a role with the DAG-based permission ``DAG:example_python_operator.can_read`` can still access that endpoint even without ``DAGS.can_read``.
```
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,116 @@ 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, Airlfow 2.0+ uses role-based access control (RBAC) to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a default set of roles:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
-'''''''''''''
+''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You can then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
-There are five default roles: Public, Viewer, User, Op, and Admin. Each one has the permissions of the preceding role, as well as additional permissions.
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG-level access.
-DAG-level permissions
-^^^^^^^^^^^^^^^^^^^^^
+DAG-level permissions differ from resource-level permissions in a few key ways:
+- Resource-based permissions apply to all DAGs, while DAG-based permissions apply only to specific DAGs.
+- DAG-based permissions control only``can_read`` and ``can_edit`` actions (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0).
+- You have to specify an existing DAG in the name of a DAG-based permission. The specific naming convention is ``DAG:<dag-name>.can_read`` or ``DAG:<dag-name>.can_edit``.
+
+For example, the following images show how you would create a role which can only write to
+``example_python_operator``. Once you create the role, the permission appears in the **List Roles** menu.
+
+.. image:: /img/add-role.png
+.. image:: /img/new-role.png
+
+If an endpoint for a specific DAG requires a permission based on the DAG resource (for example, ``DAGs.can_create``),
+a role will have access if it has either the resource-based permission or a DAG-based permission.
+
+For example, if an endpoint for the ``example_python_operator`` DAG requires the resource-based ``DAGS.can_read`` permission,
+a role with the DAG-based permission ``DAG:example_python_operator.can_read`` can still access that endpoint even without ``DAGS.can_read``.
-For DAG-level permissions exclusively, access can be controlled at the level of all DAGs or individual DAG objects. This includes ``DAGs.can_create``, ``DAGs.can_read``, ``DAGs.can_edit``, and ``DAGs.can_delete``. When these permissions are listed, access is granted to users who either have the listed permission or the same permission for the specific DAG being acted upon. For individual DAGs, the resource name is ``DAG:`` + the DAG ID.
+Reference: Action and Endpoint Permissions
+''''''''''''''''''''''''''''''''''''''''''
-For example, if a user is trying to view DAG information for the ``example_dag_id``, and the endpoint requires ``DAGs.can_read`` access, access will be granted if the user has either ``DAGs.can_read`` or ``DAG:example_dag_id.can_read`` access.
+The following tables list all of the necessary permissions required for access to various Airflow endpoints and actions. Note that the ``Minimum Role`` table only applies
+if you haven't edited your default roles.
Review comment:
```suggestion
The following tables list all of the necessary permissions required for access to various Airflow endpoints and actions. Note that the ``Minimum Role`` table only applies if you haven't edited your default roles.
```
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on a change in pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on a change in pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#discussion_r582446678
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
'''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You could then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG level access.
-There are five default roles: Public, Viewer, User, Op, and Admin. Each one has the permissions of the preceding role, as well as additional permissions.
+While access to all DAGs is controlled with resource-based permissions, DAG level access only has two associated permissions:
+``can_read`` and ``can_edit`` (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0).
-DAG-level permissions
-^^^^^^^^^^^^^^^^^^^^^
+For instance, the following images show how you would create a role which can only write to
+``example_python_operator``. Once you create the role, the permission appears in the **List Roles** menu.
+
+.. image:: /img/add-role.png
+.. image:: /img/new-role.png
+
+If an endpoint for a specific DAG requires a permission based on the DAG resource (for example, ``DAGs.can_create``),
+a role will have access if it has either the resource-based permission or a DAG-based permission.
+
+For example, if an endpoint for the ``example_python_operator`` DAG requires the resource-based ``DAGS.can_read`` permission,
+a role with the DAG-based permission ``DAG:example_python_operator.can_read`` can still access that endpoint even without ``DAGS.can_read``.
Review comment:
Do DAG-level permissions give you access to all resource-level actions for a DAG? Wondering if I should use an example with "can_read"/ "can_edit" or "can_create" to show the DAG-level permissions enable more than just the single action their name represents.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal commented on a change in pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
eladkal commented on a change in pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#discussion_r604344995
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,111 @@ 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, Airlfow 2.0+ uses role-based access control (RBAC) to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
Review comment:
```suggestion
By default, Airflow 2.0+ uses role-based access control (RBAC) to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
```
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jhtimmins commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jhtimmins commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-806224978
@jwitz looks good, just requested a few changes to remove unnecessary newlines (the docs tool will wrap the text automatically).
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on a change in pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on a change in pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#discussion_r582447103
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
'''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
Review comment:
I tried embedding these images into steps by indenting their reference. Rendered correctly in my browser, but let me know if there's another standard formatting we use for this.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on a change in pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on a change in pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#discussion_r583741108
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
'''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You could then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG level access.
-There are five default roles: Public, Viewer, User, Op, and Admin. Each one has the permissions of the preceding role, as well as additional permissions.
+While access to all DAGs is controlled with resource-based permissions, DAG level access only has two associated permissions:
+``can_read`` and ``can_edit`` (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0).
Review comment:
@jhtimmins Tried to clarify this by making a list of differences
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] github-actions[bot] commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-896395892
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
--
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-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-824935142
@jhtimmins Bumpin one more time for a final approval π
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jhtimmins commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jhtimmins commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-786397341
This looks great @jwitz, just some clarification about how DAG-level permissions work.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jwitz closed pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jwitz closed pull request #14439:
URL: https://github.com/apache/airflow/pull/14439
--
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-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jhtimmins commented on a change in pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
jhtimmins commented on a change in pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#discussion_r583360827
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
'''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You could then assign the given role to a new user using the ``airflow
Review comment:
```suggestion
You can then assign the given role to a new user using the ``airflow
```
Just for sake of consistency
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
'''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You could then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG level access.
-There are five default roles: Public, Viewer, User, Op, and Admin. Each one has the permissions of the preceding role, as well as additional permissions.
+While access to all DAGs is controlled with resource-based permissions, DAG level access only has two associated permissions:
+``can_read`` and ``can_edit`` (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0).
-DAG-level permissions
-^^^^^^^^^^^^^^^^^^^^^
+For instance, the following images show how you would create a role which can only write to
+``example_python_operator``. Once you create the role, the permission appears in the **List Roles** menu.
+
+.. image:: /img/add-role.png
+.. image:: /img/new-role.png
+
+If an endpoint for a specific DAG requires a permission based on the DAG resource (for example, ``DAGs.can_create``),
+a role will have access if it has either the resource-based permission or a DAG-based permission.
+
+For example, if an endpoint for the ``example_python_operator`` DAG requires the resource-based ``DAGS.can_read`` permission,
+a role with the DAG-based permission ``DAG:example_python_operator.can_read`` can still access that endpoint even without ``DAGS.can_read``.
Review comment:
So I think there's a bit of confusion around DAG permissions.
* Any permission with the `DAGs` prefix, such as `DAGs.can_read`, `DAG.can_delete`, etc., applies to all DAGs.
* Any permission that starts with `DAG:<dag_name>`, such as `DAG:example_python_operator.can_read` or `DAG: DAG:example_python_operator.can_edit`, only applies to that specific DAG.
Unfortunately, there isn't a consistent naming scheme that distinguishes the two cases IIRC, but DAG-level and resource-level works IMO.
To answer your question directly, each action name only gives access to a single action. This is the same for DAG-level permissions and all other permissions as well. So if I have `DAG:example_python_operator.can_read`, that only gives me the ability to read the `example_python_operator` DAG and nothing else.
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
'''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You could then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG level access.
-There are five default roles: Public, Viewer, User, Op, and Admin. Each one has the permissions of the preceding role, as well as additional permissions.
+While access to all DAGs is controlled with resource-based permissions, DAG level access only has two associated permissions:
+``can_read`` and ``can_edit`` (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0).
Review comment:
This is a bit confusing. Something along the lines of "Any resource-based permission applies to all DAGs, but it's also possible to assign `can_read` and `can_edit` to individual DAGs. (``can_dag_read`` and ``can_dag_edit`` were deprecated in 2.0.0). This was added because a lot of users wanted the ability to control who could read or run individual DAGs."
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Viewer
^^^^^^
-``Viewer`` users have limited viewer permissions
+``Viewer`` users have limited viewer permissions on limited web views. The following table lists all permissions granted to ``Viewers``:
.. 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 all of the ``Viewer`` permissions listed above, plus additional user permissions for modifying DAGs, task instances, and DAG runs:
.. 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 all of the permissions that ``Viewers`` and ``Users`` have, plus additional permissions for modifying resources like connections and pools:
.. 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
'''''''''''''
-DAG Level Role
-^^^^^^^^^^^^^^
-``Admin`` can create a set of roles which are only allowed to view a certain set of dags. This is called DAG level access. Each dag defined in the dag model table
-is treated as a ``View`` which has two permissions associated with it (``can_read`` and ``can_edit``. ``can_dag_read`` and ``can_dag_edit`` are deprecated since 2.0.0).
-There is a special view called ``DAGs`` (it was called ``all_dags`` in versions 1.10.*) which
-allows the role to access all the dags. The default ``Admin``, ``Viewer``, ``User``, ``Op`` roles can all access ``DAGs`` view.
+Creating custom roles is the recommended way to customize your environment access. To do so:
-.. image:: /img/add-role.png
-.. image:: /img/new-role.png
+1. In the **List Roles** menu, click the blue button to create a new role. Alternatively, select an existing role and click **Actions** > **Copy Role** to create a role based on your selection.
-The image shows the creation of a role which can only write to
-``example_python_operator``. You can also create roles via the CLI
-using the ``airflow roles create`` command, e.g.:
+ .. image:: /img/list-roles.png
-.. code-block:: bash
+2. Specify a name and add permissions for the role. Note that the names for permissions will vary slightly between the UI and the source code.
- airflow roles create Role1 Role2
+ .. image:: /img/add-permissions.png
-And we could assign the given role to a new user using the ``airflow
-users add-role`` CLI command.
+3. Click Save.
+You can also create roles via the CLI using the following command:
-Permissions
-'''''''''''
+.. code-block:: bash
+
+ airflow roles create <Role1> <Role2>
+
+You could then assign the given role to a new user using the ``airflow
+users add-role`` CLI command. Note that adding and removing permissions for a role can only be completed in the UI.
Resource-Based permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Starting with version 2.0, permissions are based on individual resources and a small subset of actions on those
+Starting with version 2.0, permissions are based on individual resources and a small set of actions with those
resources. Resources match standard Airflow concepts, such as ``Dag``, ``DagRun``, ``Task``, and
``Connection``. Actions include ``can_create``, ``can_read``, ``can_edit``, and ``can_delete``.
-Permissions (each consistent of a resource + action pair) are then added to roles.
+Each endpoint in Airflow requires one or more permissions to be accessed. To access an endpoint, a role needs all permissions required by that endpoint.
-**To access an endpoint, the user needs all permissions assigned to that endpoint**
+DAG-Based Permissions
+^^^^^^^^^^^^^^^^^^^^^
+``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG level access.
Review comment:
```suggestion
``Admin`` users can create roles with permission to access only specific DAGs. This is called DAG-level access.
```
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] ashb commented on a change in pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
ashb commented on a change in pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#discussion_r582976024
##########
File path: docs/apache-airflow/security/access-control.rst
##########
@@ -37,101 +37,113 @@ 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.
+
+Airflow uses roles to manage all permissions across your environment. Each role has permissions which provide varying levels of access to Airflow's key resources (DAGs, Connections, etc).
+
+An environment's roles can be found under the **Security** tab:
+
+.. image:: /img/list-roles.png
+
+Airflow ships with a set of roles by default:
Admin
^^^^^
``Admin`` users have all possible permissions, including granting or revoking permissions from
other users.
+Only ``Admin`` users can configure/alter the permissions for other roles. While they can reconfigure Airflow's other default rules, it's not recommended.
+The best practice is to instead create a new role with the desired permissions.
+
Public
^^^^^^
``Public`` users (anonymous) don't have any permissions.
Review comment:
Public is the role you get when you aren't logged in -- if you gave some permissions to this you could let all people with access to your Airflow webserver view things.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] github-actions[bot] commented on pull request #14439: Updated the latest version of the "Access Control" doc with new screenshots/ content
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #14439:
URL: https://github.com/apache/airflow/pull/14439#issuecomment-785507882
The PR is likely ready to be merged. No tests are needed as no important environment files, nor python files were modified by it. However, committers might decide that full test matrix is needed and add the 'full tests needed' label. Then you should rebase it to the latest master or amend the last commit of the PR, and push it with --force-with-lease.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org