I agree with all the points as well. Well documented content = less confusion!
> 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: ✴️✴️✴️ Just for clarity's sake, the export command gets asterisk / obfuscated passwords! Jens -- exporting in kubectl will give out k8s secrets in b64 encoded fashion :) (It's fairly easy to decode it, but still it's not plain text) Example: *kubectl get secret my-secret -o yamlapiVersion: v1data: username: YWWWRtaW4= password: MWYyZDDDFlMmU2N2DRmkind: Secretmetadata: name: my-secrettype: Opaque* Thanks & Regards, Amogh Desai On Tue, Nov 4, 2025 at 2:48 AM Jens Scheffler <[email protected]> wrote: > I agree as well. We shoudl clearly document this such that nobody raises > a bug ticket about missing export in future. > > Whereas I am scratching my head a bit, in kubectl (in contrast to > airflowctl in future) it is possible to export all and everything as > YAML, also secrets. But yeah makes it more consistent. Nevertheless if > exported via CLI, it should be possible to import via UI / airflowctl. > > On 11/3/25 21:00, Brent Bovenzi via dev wrote: > > 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. > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
