I agree. I would feel much better if the REST API and UI never had to worry about correctly checking if sensitive values should be displayed.
On Mon, Nov 3, 2025 at 2:18 PM Jarek Potiuk <[email protected]> wrote: > Hello here, > > *TL;DR; We had recently a discussion (or rather few parallel discussions) > about sensitive values exposure (Connections and Variables mainly) and how > we want to standardise it in places where it is inconsistent and I wanted > to discuss a proposal we have. We agreed it's not disclosing any security > issue, so we want to discuss it in public and get to a consensus.* > > I **think** we got to a consensus in the security team that I want to > propose and see what others in the community think. > > *# The context of change from Airflow 2 => Airflow 3 ✈️* > > In Airflow 3 sensitive connections and variables were exposed in two ways: > CLI for the local admin users and via API for the UI and API users (for > users who had Connection Editing permission). > > This was documented in our Security Model in Airflow 2 [1]. In Airflow > 3.0.0 - 3.0.3 we **somehow** changed the model but it was not a widespread > knowledge (including in the Security team). The API changed to mask the > values that were sensitive (and stayed like that till 3.0.3. > > In 3.0.3 we exposed the sensitive connections, by a "connection editing > bugfix" 🐛 - where we thought we still had the model of Airflow 2. We > reverted it in 3.0.4 and implemented another bugfix, announced the CVE [2] > and updated our model to reflect that [3] > > The new model says: 📃 > > *> Before Airflow 3, the Connection configuration users role had also > access to view the sensitive information. This has been changed in Airflow > 3 to improve security of the accidental spilling of credentials of the > connection configuration users. Previously - in Airflow 2 - the Connection > configuration users had deliberately access to view the sensitive > information and could either reveal it by using Inspect capabilities of the > browser or they were plain visible in case of the sensitive credentials > stored in configuration extras. Airflow 3 and later versions include a > security improvement to mask those sensitive credentials at the API level.* > > This effectively turned Connections and Variables to be "write-only" from > the API point of view. If you have "connection editing" permission, you can > update the sensitive values but you can't read them. Only those who can > access CLI locally can read/write the sensitive data. > > So far, so good. ✅ > > *# The problem 🤔* > > I believe the model is good now and we should keep it. However there are > few inconsistencies around import/export and showing sensitive values on > local "list CLI", and new beast (remote CLI) that I think we agreed to and > capture in our model. One of the consequences of the model is the > issue reported by David Blain [4] where instead of passwords in variables > exported via UI we see this: ✴️✴️✴️ > > Another thing that Constance noticed is that "list" for connections (and > also for configuration) - shows by default all possible sensitive values in > all connections - which (while CLI remote user is capable of it - makes it > quite sensitive on its own (all your secrets are suddenly visible in your > terminal 🙀😱. We thought this is a bit (just a bit) too open and there is > an inconsistency that *variables list* - only currently shows list of > variable ids, where *connections list* - returns all details (including > sensitive data). Similarly *config list *contains sensitive data. > > We want to avoid (gain) the situation where things are changed in PR and > others are unaware, so we want to make sure that we agree with it here and > document it in our CLI and Security Model description. > > *# The proposal ‼️* > > 1) we want to make it crystal clear that no APIs ever expose sensitive data > > 2) that means that we should remove export (and likely import) via UI - and > leave a comment that export/import is only available via local CLI > > 3) the "sensitive data not exposed over API" is also present in airflow-ctl > - this means that airflow-ctl should never expose sensitive data (including > connections, variables, config) > > 4) the "expose config" [5] - will only accept "*false*" and " > *non-sensitive-only*". The "true" will be rejected. > > 5) local CLI ** list* (connections, variables, config) only by default > returns "keys" - and it will only return values when `*--show-values*` is > passed as command line option (with clear comment in help that this option > **might** show sensitive data, also when we do `** list*` command without > `--show-values` we emit stderr output explaining that potentially sensitive > data is hidden and you need to specify `--show-values` to see them > > 6) the ** get* commands are unaffected (those are more likely already used > as CLI API > > 7) we remove *connections list --conn-id *as it is equivalent to > *connections > get * > > > > Please respond in the thread and let us know what you think. ⁉️🙋 > Hopefully we might get to a consensus and officially ask for it soon. > > > Thanks to Constance who raised some concerns about it and thanks to David > for opening the issue - this triggered the discussions. > > [1] Security Model in Airflow 2: > > https://airflow.apache.org/docs/apache-airflow/2.11.0/security/security_model.html > [2] CVE about unmasked connection secrets in Airflow 3.0.3 > [3] Security Model in Airflow 3: > > https://airflow.apache.org/docs/apache-airflow/stable/security/security_model.html > [4] Issue with not working Variable Export in UI > https://github.com/apache/airflow/issues/57428 > [5] Expose config parameter > > https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#expose-config > > > J. >
