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]
