> 2. Import could stay. It’s a bulk create — it does no harm in existing, so I don’t see why we should remove it
Absolutely yes. No problem with it - good point Ash, Artitra. It was mostly as a kind of "import/export" being treated as "counterparts" - but yes absolutely, there is no problem with leaving import in airflow-ctl and UI an API - as long as we also clearly document how to do export (with local CLI) and explain why "export" is not there (again - avoiding surprise effect). > 3. Just to clarify (what I assume you mean) no sensitive/unredacted data should be sent over the API, so the this is not airflowctl’s responsibility to care about, just a statement of intent/behaviour, yes? Yes. That's the statement of intent, but it's also more of a "server-side" statement. It's the SERVER side that should never expose any sensitive data. So it really does not matter what airflow ctl does, because it should be **impossible** to get the that data over any kind of API. Basing security on client side behaviour (as Brent correctly noticed) is a bad idea - clients should **never** worry about it. > 5. I might say we should show some values (host, port etc) just not anything sensitive without an extra flag — just listing connection ids or everything seems like to far to either extreme. Yes, that's also an option we can consider. This is what we currently plan to do currently with `4) the "expose config" [5] - will only accept "*false*" and "*non-sensitive-only*". The "true" will be rejected.` -> we are redacting sensitive data only when "expose-config" is "non-sensitive-only", However, in case of the local CLI "list" command I think it would make more sense to only show list and make the behaviour consistent with "variables list" for example (and to avoid surprise at the comment that all data - including sensitive) can be shown with `--show-values). We already know that the local CLI user has access to the data anyway, they can expose them with explicit `--show-value`. And here, what we REALLY want to protect against accidental printing of too much sensitive data to the terminal. I would argue that having a "wall" of connection data with sensitive information masked or removed is kinda useless (especially when you want to show it - for example - in json format). Likely you already have a good reason (for example automation) to specify `--show-values` when you actually want to see ALL values (including sensitive) in the output. So I think - personally - it's better to only show list of ids by default and show all details (including sensitive) for local CLI (and not have to deal with masking for local CLI at all - this also might give a false sense of security and someone might think that masking means that local CLI user cannot see the sensitive data at all). Also one small thing (following what Jens and Amogh wrote). I did not want to mention that in the original email to not make it any more complex. There is POTENTIALLY an option we could allow export via API - we would have to encrypt - either the whole export or sensitive data, with the key that the remote user does not have access to (FERNET_KEY of ours is a good candidate). This would have all the right security properties. But I think, personally it's still a bit risky and it has additional complexities - you have to make sure you have not changed the FERNET_KEY between export and import, and you won't be able to perform an export / import between instances of Airflow with a different FERNET_KEY. We might consider that option, however, if others think it's a viable one. J, On Tue, Nov 4, 2025 at 10:41 AM Aritra Basu <[email protected]> wrote: > I'm mostly in agreement with Ash, I think we should keep import atleast. > From a usability perspective it makes sense to be able to perform some of > these setup flows from the UI. The rest sounds good to me. > > -- > Regards, > Aritra Basu > > On Tue, 4 Nov 2025, 2:53 pm Ash Berlin-Taylor, <[email protected]> wrote: > > > Largely agreed, a few questions/comments: > > > > 2. Import could stay. It’s a bulk create — it does no harm in existing, > so > > I don’t see why we should remove it > > > > 3. Just to clarify (what I assume you mean) no sensitive/unredacted data > > should be sent over the API, so the this is not airflowctl’s > responsibility > > to care about, just a statement of intent/behaviour, yes? > > > > 5. I might say we should show some values (host, port etc) just not > > anything sensitive without an extra flag — just listing connection ids or > > everything seems like to far to either extreme. > > > > -a > > > > > On 3 Nov 2025, at 19:16, Jarek Potiuk <[email protected]> wrote: > > > > > > 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 * > > > > >
