saurabhb-dev commented on code in PR #60564:
URL: https://github.com/apache/airflow/pull/60564#discussion_r2693161710
##########
airflow-core/docs/authoring-and-scheduling/assets.rst:
##########
@@ -143,7 +143,9 @@ In the example below, the final stored ``extra`` value is
not guaranteed and it
# It's not guaranteed which extra will be the one stored
-.. note:: **Security Note:** Asset URIs and values in the ``extra`` field are
stored in cleartext in Airflow's metadata database. These fields are **not
encrypted**. **DO NOT** store sensitive information, especially credentials, in
either the asset URI or the ``extra`` dictionary.
+.. Security Warnings::
+1. **Secure naming of asset URIs:** Asset URIs and values in the ``extra``
field are stored in cleartext in Airflow's metadata database. These fields are
**not encrypted**. **DO NOT** store sensitive information, especially
credentials, in either the asset URI or the ``extra`` dictionary.
+2. **Security Implication of Asset Creation**: In Airflow's security model,
granting the ``can_create`` permission on Assets is effectively equivalent to
granting "trigger" permissions on all downstream DAGs that depend on those
assets. Because Airflow uses an "implicit trust" model for data-aware
scheduling, any user who can create an Asset Event (via the API or a task) can
trigger any DAG scheduled on that asset, even if the user does not have
permission to view or edit the downstream DAGs. Exercise caution when granting
``can_create`` on Assets in multi-tenant environments, as it allows users to
influence workflows outside their direct scope.
Review Comment:
Thanks. It makes sense to ensure consistency with other Airflow docs pages.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
