Clarify our security model for sensitive connection information by potiuk · Pull Request #54088 · apache/airflow

potiuk · 2025-08-04T11:35:22Z

The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen.

This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

pierrejeambrun

Thanks Jarek, looks good, just one suggestion.

The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

…mation (#54088) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

github-actions · 2025-08-04T16:42:02Z

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test

…mation (apache#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…mation (#54088) (#54100) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…he#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

potiuk · 2025-08-04T11:35:22Z

The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen.

This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

pierrejeambrun

Thanks Jarek, looks good, just one suggestion.

The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

…mation (#54088) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

github-actions · 2025-08-04T16:42:02Z

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test

…mation (apache#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…mation (#54088) (#54100) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…he#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

potiuk · 2025-08-04T11:35:22Z

The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen.

This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

pierrejeambrun

Thanks Jarek, looks good, just one suggestion.

The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

…mation (#54088) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

github-actions · 2025-08-04T16:42:02Z

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test

…mation (apache#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…mation (#54088) (#54100) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…he#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

potiuk · 2025-08-04T11:35:22Z

The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen.

This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

pierrejeambrun

Thanks Jarek, looks good, just one suggestion.

The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

…mation (#54088) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

github-actions · 2025-08-04T16:42:02Z

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test

…mation (apache#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…mation (#54088) (#54100) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…he#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

potiuk · 2025-08-04T11:35:22Z

The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen.

This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

pierrejeambrun

Thanks Jarek, looks good, just one suggestion.

The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

…mation (#54088) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

github-actions · 2025-08-04T16:42:02Z

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test

…mation (apache#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…mation (#54088) (#54100) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…he#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

potiuk · 2025-08-04T11:35:22Z

The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen.

This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

pierrejeambrun

Thanks Jarek, looks good, just one suggestion.

The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

…mation (#54088) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

github-actions · 2025-08-04T16:42:02Z

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test

…mation (apache#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…mation (#54088) (#54100) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…he#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

potiuk · 2025-08-04T11:35:22Z

The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen.

This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

pierrejeambrun

Thanks Jarek, looks good, just one suggestion.

The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

…mation (#54088) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

github-actions · 2025-08-04T16:42:02Z

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test

…mation (apache#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…mation (#54088) (#54100) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…he#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

potiuk · 2025-08-04T11:35:22Z

The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen.

This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

pierrejeambrun

Thanks Jarek, looks good, just one suggestion.

The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

…mation (#54088) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

github-actions · 2025-08-04T16:42:02Z

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test

…mation (apache#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…mation (#54088) (#54100) The #53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data. (cherry picked from commit f5a88d9) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

…he#54088) The apache#53973 introduced a change in the model of handling of the sensitive connection data in the Airlfow UI. Previoiusly our agreed model included capability of reading sensitive data bu the users who have Connection Configuraiton role. However in 3.0.4 we changeed the model so that those users have "write-only" access - they can write the sensitive data, but they cannot read the data via API or the UI once it is written. WHile not a security vulnerability on it's own, it's a security improvement that allows to mitigate some scenarios, especially when connection editing user credentials are stolen. This PR clarifies the model and properly communicates it to the users clearly indicating the difference implemented in 3.0.4 and the model of our security and clearly explaining that before 3.0.4 that was a delibearate choice of the model that the connection editing users had access to the sensitive data.

boring-cyborgBot added the kind:documentation label Aug 4, 2025

potiuk mentioned this pull request Aug 4, 2025
Export import for connections for airflowctl is broken in main #54090
Closed
2 tasks

pierrejeambrun reviewed Aug 4, 2025
View reviewed changes

Comment threadairflow-core/docs/security/security_model.rst Outdated

potiuk force-pushed the add-security-mydel-update branch from 78176b5 to 6ee1038Compare August 4, 2025 12:43

pierrejeambrun approved these changes Aug 4, 2025
View reviewed changes

potiuk added this to the Airflow 3.0.4 milestone Aug 4, 2025

potiuk added the backport-to-v3-0-test label Aug 4, 2025

potiuk merged commit f5a88d9 into apache:mainAug 4, 2025
58 checks passed

potiuk deleted the add-security-mydel-update branch August 4, 2025 16:41