I agree that this shouldn't be a client-side gate. I also agree that we should securely enable the capability via the API in the future. Including an additional parameter seems simpler if we want to make filtering out the CLI the default behaviour. We should document this clearly, as everyone has suggested. It should be referenced consistently, either through a link or an explanation of what the component does for this use case, while the Security model can detail higher-level aspects in the documentation. We should clearly document CLI, API, and CTL separately so users of these components are aware, or can easily become aware, just by reading the documentation.
I don't believe kubectl manages whether secrets are kept in base64 or not. It certainly doesn't default to plain text. There are a couple of base64 operations, but they are not related to encoding secrets to base64. Small addition to all info :) On Tue, Nov 4, 2025 at 12:55 PM Jarek Potiuk <[email protected]> wrote: > > 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 * > > > > > > > > > -- Bugra Ozturk
