I will call for lazy consensus - it's been a while since last activity. On Tue, Nov 4, 2025 at 9:38 PM Buğra Öztürk <[email protected]> wrote: > > 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
