Just a comment. Explaining how to disable it is almost the same as officially making it production-ready but without guarantees. Look how many people are using sequential executor despite having the warning. If we tell people how to disable it easily, they will just use it. Plenty of themm.
And I am not against it. I would've for it and make it ready, rather than pretending it is not happening and getting hit be some security issue raised to us because big percentage of our users will just use it. J. czw., 27 mar 2025, 18:29 użytkownik Daniel Standish <daniel.stand...@astronomer.io.invalid> napisał: > So yes we can make it friendlier and then tell users how it can be disabled > by config. > > On Thu, Mar 27, 2025 at 10:28 AM Daniel Standish < > daniel.stand...@astronomer.io> wrote: > > > There needs to be a way to disable the banner IMO > > > > On Thu, Mar 27, 2025 at 10:20 AM Kaxil Naik <kaxiln...@gmail.com> wrote: > > > >> message cut: > >> > >> I am fine with Option (1) given the current time constraints and since > it > >> is for dev only and can be iterated in follow-up releases > >> > >> > >> On Thu, 27 Mar 2025 at 22:47, Kaxil Naik <kaxiln...@gmail.com> wrote: > >> > >> > I am fine with Option (1) imo > >> > > >> > On Thu, 27 Mar 2025 at 22:05, Vincent Beck <vincb...@apache.org> > wrote: > >> > > >> >> Following back on that thread (I should probably have called it out > >> >> during the Airflow 3 dev call). We have two options: > >> >> - Option 1: update the banner with a friendlier message > >> >> - Option 2: resolve the security issue to make SAM production > >> compatible > >> >> and remove the banner > >> >> > >> >> Any preference on which option we should go with? > >> >> > >> >> On 2025/03/24 16:52:11 "Oliveira, Niko" wrote: > >> >> > Agreed, I think combining the two will make SAM not so simple. But > we > >> >> should definitely have an open source, easy to acquire option for > >> people to > >> >> use that has all the bells and whistles that SAM does not have. And > >> >> KeyCloack is a decent option for this! > >> >> > > >> >> > ________________________________ > >> >> > From: Vincent Beck <vincb...@apache.org> > >> >> > Sent: Monday, March 24, 2025 6:04:42 AM > >> >> > To: dev@airflow.apache.org > >> >> > Subject: RE: [EXT] [DISCUSS] confusing alert re SimpleAuthManager > >> >> > > >> >> > CAUTION: This email originated from outside of the organization. Do > >> not > >> >> click links or open attachments unless you can confirm the sender and > >> know > >> >> the content is safe. > >> >> > > >> >> > > >> >> > > >> >> > AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur > >> >> externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si > >> vous > >> >> ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes > >> pas > >> >> certain que le contenu ne présente aucun risque. > >> >> > > >> >> > > >> >> > > >> >> > I do not think integrating KeyCloak with SAM is a great idea. > Having > >> a > >> >> separate auth manager specific to KeyCloak is, on the other side, a > >> good > >> >> idea. We should keep SAM simple as it is. I also do not think making > it > >> >> secure require a lot of work so I do not think it is worth having a > >> >> development and production mode. > >> >> > > >> >> > On 2025/03/21 21:52:13 Buğra Öztürk wrote: > >> >> > > Giving users a warning sounds good. > >> >> > > I agree with Pierre, too. How about defining the rules set to be > >> >> secure by > >> >> > > design? Or just following up on a pattern without discovering > >> >> something > >> >> > > new? Could you please elaborate on Jarek? > >> >> > > > >> >> > > *TLDR* > >> >> > > It may be a slight implementation detail and just a thought, but > we > >> >> could > >> >> > > integrate Keycloak into the SAM, providing development and > >> production > >> >> modes > >> >> > > with configurations such as breeze dev and installation prod. I > >> >> believe > >> >> > > that instead of maintaining an application to always be secure by > >> >> default, > >> >> > > we can focus on maintaining integration within SAM. > >> >> > > > >> >> > > On Fri, Mar 21, 2025 at 7:28 PM Vincent Beck < > vincb...@apache.org> > >> >> wrote: > >> >> > > > >> >> > > > We could simply stop printing out these passwords. Passwords > are > >> >> auto > >> >> > > > generated if not already defined in a file configured in > `[core] > >> >> > > > simple_auth_manager_passwords_file`. So the user can see these > >> >> passwords by > >> >> > > > opening this file. We could (if it is not considered as > >> unsecured?) > >> >> print > >> >> > > > out the filename in the stdout so that the user can click on it > >> and > >> >> see the > >> >> > > > passwords only if some passwords changed. > >> >> > > > > >> >> > > > On 2025/03/21 18:03:19 Jarek Potiuk wrote: > >> >> > > > > Well.. Actually Pierre is quite right. While we have not > >> intended > >> >> Simple > >> >> > > > > Auth Manager for production it **could** be used. > >> >> > > > > > >> >> > > > > However we would have to carefully think what to do with > >> default > >> >> > > > passwords > >> >> > > > > etc. Currently a lot of warnings in CodeQL were about > "writing > >> >> sensitive > >> >> > > > > information to logs" - and a lot of that is about SAM (nice > >> >> acronym BTW) > >> >> > > > > writing the generated passwords to logs and stdout. And I > >> >> dismissed it as > >> >> > > > > "Used in tests" for SAM cases. > >> >> > > > > > >> >> > > > > So if we decide to use it, we need to decide how to deal with > >> the > >> >> > > > password > >> >> > > > > generation and default users. We should follow (and this in > the > >> >> future > >> >> > > > will > >> >> > > > > be even mandated by various regulations like CRA) is "secure > by > >> >> default". > >> >> > > > > Which means that default installation MUST be secure. Once we > >> >> solve > >> >> > > > this, I > >> >> > > > > am fine with using SAM in production > >> >> > > > > > >> >> > > > > J. > >> >> > > > > > >> >> > > > > > >> >> > > > > On Fri, Mar 21, 2025 at 6:27 PM Pierre Jeambrun < > >> >> pierrejb...@gmail.com> > >> >> > > > > wrote: > >> >> > > > > > >> >> > > > > > Is it really wrong to use the SimpleAuthManager in > >> production ? > >> >> To my > >> >> > > > > > knowledge it lacks a lot of features such as user > management > >> >> and the > >> >> > > > > > permission model is really simplistic, but maybe some > >> >> installations > >> >> > > > don’t > >> >> > > > > > need the fancy Auth stuff ? > >> >> > > > > > > >> >> > > > > > Instead of being a scary warning that could be just an info > >> >> block, with > >> >> > > > > > details and mention of other Auth Manager in case more use > >> >> cases need > >> >> > > > to be > >> >> > > > > > supported. (Or link to doc etc) > >> >> > > > > > > >> >> > > > > > Also we can easily add a “don’t show again” box or > something > >> >> like that, > >> >> > > > > > stored on the client side and remove the message if chosen > by > >> >> the > >> >> > > > user. (Or > >> >> > > > > > even a global config setting for all users). > >> >> > > > > > > >> >> > > > > > On Fri 21 Mar 2025 at 16:03, Vincent Beck < > >> vincb...@apache.org> > >> >> wrote: > >> >> > > > > > > >> >> > > > > > > This alert can be definitely improved. I do think we > should > >> >> have it > >> >> > > > and > >> >> > > > > > we > >> >> > > > > > > should not remove it. If you have some proposals, please > >> feel > >> >> free to > >> >> > > > > > > create a PR, I'll be happy to review. Mentioning the > other > >> >> auth > >> >> > > > managers > >> >> > > > > > as > >> >> > > > > > > alternatives is, I think, a great idea. > >> >> > > > > > > > >> >> > > > > > > On 2025/03/21 07:20:26 Amogh Desai wrote: > >> >> > > > > > > > Hmmm, I wonder if it can instead be made clearer. > >> Something > >> >> like > >> >> > > > this? > >> >> > > > > > > > > >> >> > > > > > > > *Simple Auth Manager Enabled.* > >> >> > > > > > > > *The Simple Auth Manager is intended for development > and > >> >> testing. > >> >> > > > If > >> >> > > > > > > you're > >> >> > > > > > > > using it in production, ensure that access is > controlled > >> >> through > >> >> > > > other > >> >> > > > > > > > means. * > >> >> > > > > > > > *<link some doc>* > >> >> > > > > > > > > >> >> > > > > > > > Thanks & Regards, > >> >> > > > > > > > Amogh Desai > >> >> > > > > > > > > >> >> > > > > > > > > >> >> > > > > > > > On Thu, Mar 20, 2025 at 11:58 PM Daniel Standish > >> >> > > > > > > > <daniel.stand...@astronomer.io.invalid> wrote: > >> >> > > > > > > > > >> >> > > > > > > > > I'm saying, sounds confusing! > >> >> > > > > > > > > > >> >> > > > > > > > > On Thu, Mar 20, 2025 at 11:27 AM < > >> consta...@astronomer.io > >> >> > > > .invalid> > >> >> > > > > > > wrote: > >> >> > > > > > > > > > >> >> > > > > > > > > > Sounds great! Do we have something in the config > >> linter > >> >> to > >> >> > > > > > highlight > >> >> > > > > > > this > >> >> > > > > > > > > > change? > >> >> > > > > > > > > > > >> >> > > > > > > > > > > On Mar 20, 2025, at 11:19 PM, Daniel Standish > >> >> > > > > > > > > > <daniel.stand...@astronomer.io.invalid> wrote: > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > It says this: > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > Development-only auth manager configured > >> >> > > > > > > > > > > The auth manager configured in your environment > is > >> >> the Simple > >> >> > > > > > Auth > >> >> > > > > > > > > > Manager, > >> >> > > > > > > > > > > which is intended for development use only. It is > >> not > >> >> > > > suitable > >> >> > > > > > for > >> >> > > > > > > > > > > production and should not be used in a production > >> >> > > > environment. > >> >> > > > > > > > > > > > >> >> > > > > > > > > > >> On Thu, Mar 20, 2025 at 10:48 AM Jarek Potiuk < > >> >> > > > ja...@potiuk.com > >> >> > > > > > > > >> >> > > > > > > > > wrote: > >> >> > > > > > > > > > >> > >> >> > > > > > > > > > >> What's the alert - at least for me it did not > get > >> >> through > >> >> > > > > > > > > > >> > >> >> > > > > > > > > > >> On Thu, Mar 20, 2025 at 6:33 PM Daniel Standish > >> >> > > > > > > > > > >> <daniel.stand...@astronomer.io.invalid> wrote: > >> >> > > > > > > > > > >> > >> >> > > > > > > > > > >>> I should add, the import here is, many users > who > >> >> never > >> >> > > > > > customized > >> >> > > > > > > > > auth > >> >> > > > > > > > > > >>> before will now see this message and not really > >> >> have a clue > >> >> > > > > > what > >> >> > > > > > > they > >> >> > > > > > > > > > are > >> >> > > > > > > > > > >>> supposed to do, and I think it will probably > >> create > >> >> a good > >> >> > > > > > > amount of > >> >> > > > > > > > > > >>> confusion. > >> >> > > > > > > > > > >>> > >> >> > > > > > > > > > >>> On Thu, Mar 20, 2025 at 10:27 AM Daniel > Standish > >> < > >> >> > > > > > > > > > >>> daniel.stand...@astronomer.io> wrote: > >> >> > > > > > > > > > >>> > >> >> > > > > > > > > > >>>> I just saw this when spinning up airflow > >> >> > > > > > > > > > >>>> > >> >> > > > > > > > > > >>>> [image: image.png] > >> >> > > > > > > > > > >>>> > >> >> > > > > > > > > > >>>> I think the message is confusing / misleading > / > >> >> not very > >> >> > > > > > > helpful. > >> >> > > > > > > > > > >>>> > >> >> > > > > > > > > > >>>> There's nothing necessarily wrong with having > >> >> simple auth > >> >> > > > or > >> >> > > > > > no > >> >> > > > > > > auth > >> >> > > > > > > > > > if > >> >> > > > > > > > > > >>>> you control access some other way. Moreover > we > >> >> don't tell > >> >> > > > > > users > >> >> > > > > > > > > what > >> >> > > > > > > > > > >> they > >> >> > > > > > > > > > >>>> should do instead! > >> >> > > > > > > > > > >>>> > >> >> > > > > > > > > > >>>> So I think we should either remove this bubble > >> or > >> >> add more > >> >> > > > > > > nuance > >> >> > > > > > > > > and > >> >> > > > > > > > > > >>>> point them in a direction that will lead them > to > >> >> what we > >> >> > > > *do* > >> >> > > > > > > > > > recommend. > >> >> > > > > > > > > > >>>> > >> >> > > > > > > > > > >>>> > >> >> > > > > > > > > > >> > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > >> >> --------------------------------------------------------------------- > >> >> > > > > > > > > > To unsubscribe, e-mail: > >> >> dev-unsubscr...@airflow.apache.org > >> >> > > > > > > > > > For additional commands, e-mail: > >> >> dev-h...@airflow.apache.org > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> --------------------------------------------------------------------- > >> >> > > > > > > To unsubscribe, e-mail: > dev-unsubscr...@airflow.apache.org > >> >> > > > > > > For additional commands, e-mail: > >> dev-h...@airflow.apache.org > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> --------------------------------------------------------------------- > >> >> > > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > >> >> > > > For additional commands, e-mail: dev-h...@airflow.apache.org > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > -- > >> >> > > Bugra Ozturk > >> >> > > > >> >> > > >> >> > > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > >> >> > For additional commands, e-mail: dev-h...@airflow.apache.org > >> >> > > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > >> >> For additional commands, e-mail: dev-h...@airflow.apache.org > >> >> > >> >> > >> > > >
