Username and password being always the same is also a problem; username is viewable as plain text in the UI and things like password managers.
> On 28 Mar 2025, at 02:56, Vincent Beck <vincb...@apache.org> wrote: > > Is the security issue only printing out the passwords in stdout? If yes, I > can easily remove that. > > On 2025/03/27 18:29:27 Jarek Potiuk wrote: >> 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 >>>>>>> >>>>>>> >>>>> >>>> >>> >> > > --------------------------------------------------------------------- > 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
