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
