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 fi
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...@astron
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. *
**
Thanks & Regards,
Amogh Desai
On T
Option 2 seems to require some more time?
Looking at the thread above, I think a reasonable thing to do with the
current time lines is to do 1. which most
people are proposing anyways.
Coming to the username and password being the same in breeze, I personally
find that OK and would find it harder
But like, recall in airflow 2 there was some capability to do auth role
public. I.e. no security. And we did not show a bubble for that, I don't
think. And many users would implement security not within airflow itself
but in controlling access to airflow.
So, as long as there's some mechanism t
Given the different concerns to consider SAM as secured for production use and
time, I decided to go with option 1. We can always iterate on it later and
update SAM to make it production ready if we want to.
I created a PR to update the banner, I used the text proposed by Amogh and I
converted
Yeah. Maybe a good solution would be to correlate the random password with
removing the banner.
I would be pretty happy if in order to disable the banner user(s) would
have to be securely configured by the deployment manager - essentially
converting the developement friendly (development only) SA
This is only the case in breeze so I do not think this is a concern. Breeze is
only for development purposes. When used outside of breeze, simple auth manager
generate automatically random passwords
On 2025/03/27 19:00:11 Tzu-ping Chung wrote:
> Username and password being always the same is als
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 wrote:
>
> Is the security issue only printing out the passwords in stdout? If yes, I
> can easily remove tha
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 peo
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
There needs to be a way to disable the banner IMO
On Thu, Mar 27, 2025 at 10:20 AM Kaxil Naik 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
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 wrote:
>
>> message
I am fine with Option (1) imo
On Thu, 27 Mar 2025 at 22:05, Vincent Beck 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 secur
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 wrote:
> I am fine with Option (1) imo
>
> On Thu, 27 Mar 2025 at 22:05, Vincent Beck wrote:
>
>> Following
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 whic
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: Vin
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
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
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 w
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 in
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
I'm saying, sounds confusing!
On Thu, Mar 20, 2025 at 11:27 AM 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
> wrote:
> >
> > It says this:
> >
> > Development-only auth manager configured
> > Th
Sounds great! Do we have something in the config linter to highlight this
change?
> On Mar 20, 2025, at 11:19 PM, Daniel Standish
> wrote:
>
> It says this:
>
> Development-only auth manager configured
> The auth manager configured in your environment is the Simple Auth Manager,
> which is i
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 Jar
What's the alert - at least for me it did not get through
On Thu, Mar 20, 2025 at 6:33 PM Daniel Standish
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 w
26 matches
Mail list logo
