-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable native & file realms unless explicitly disabled #50892
Comments
Pinging @elastic/es-security (:Security/Authentication) |
I don't think the code well supports multiple file realms? I mean you can add multiple file realms but they end up using the same backing file. If user configures a file realm with name other than "default_file", I think we should also disable the default one. With option 2, what should the code do if user writes |
We discussed in the Security Area meeting and agreed that we want to do this (keep file+native realms enabled unless explicitly disabled) but did not reach a consensus on which implementation option was preferred. I'm removing |
…9320) As a precursor for #50892, this PR deprecate the behaviour of file and/or native realm being implicitly disabled when there are other explicitly configured realms. With this change, the recommend way of disabling file/native realm is to explicitly set enabled to false, e.g.: xpack.security.authc.realms.file.default_file.enabled: false This PR ensures that a warning is generated whenever file and/or native realm is implicitly disabled. This change also brings a question about the order parameter. Currently, the order parameter is mandatory in 8.0 and gets a warning message if it is missing in 7.x. However, it makes sense to not specify the order parameter if the realm is disabled. So I also updated the order parameter related code to do just that.
At the moment we enable "default_native" and "default_file" realms if there are no other realms in the realm chain.
So, the out-of-the-box experience is that native users work.
If you add a realm to the realm chain you lose both the native and file realm, and are expected to configure them explictly.
So, for example, when an admin configures a SAML realm, but fails to add a native or file realm, then their native users will lose acess to the cluster.
The admin will do some research & work out the problem and then configure the native realm, but will often not add the file realm back.
There are 2 problems here.
I propose that, in ES 8.0, we add a native and file realm to the realm chain unless the configuration explicitly disables them.
I think there are 3 rough options:
xpack.security.authc.enable_native
that default totrue
. If true, we add a native & file realm to the realm chain, unless they are already in the realm chain.enabled: false
.Option (3) is the most explicit. The realm chain is always a true reflection of the cluster's security configuration, and we never mess with it behind the scenes. However, it is not very user friendly. The example above of configuring the SAML realm would fail and we would force the admin to jump through hoops to make the node start.
Option (1) doesn't feel like it adds anything over option (2).
Based on favouring user friendliness over explicit (though an admin can chose to be explicit if they want), I favour option (2).
The text was updated successfully, but these errors were encountered: