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
