-
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
Do not load SSLService in plugin contructor #49667
Conversation
XPackPlugin created an SSLService within the plugin contructor. This has 2 negative consequences: 1. The service may be constructed based on a partial view of settings. Other plugins are free to add setting values via the additionalSettings() method, but this (necessarily) happens after plugins have been constructed. 2. Any exceptions thrown during the plugin construction are handled differently than exceptions thrown during "createComponents". Since SSL configurations exceptions are relatively common, it is far preferable for them to be thrown and handled as part of the createComponents flow. This commit moves the creation of the SSLService to XPackPlugin.createComponents, and alters the sequence of some other steps to accommodate this change. Relates: elastic#44536
Pinging @elastic/es-security (:Security/Network) |
I added a few FIXME/TODOs in here for other places where we are incorrectly creating components/reading settings during construction. I will work through fixing those in separate PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. To be clear about use of settings in the ctor, it may eventually work when/if we split out setting registration into a separate plugin class that gets loaded before the actual plugin, as we have discussed to allow validation of secure setting names in elasticsearch-keystore, but moving away from them now would be correct for the reason you noted in the TODO comments.
* Create a new SSLService using the {@code Settings} from {@link Environment#settings()}. | ||
* @see #SSLService(Settings, Environment) | ||
*/ | ||
public SSLService(Environment environment) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we still need the other ctor? I only see 2 non test uses of the other ctor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need it, but there's a lot of test uses that would cause this PR to get quite big. I'm going to remove the old constructor in a follow-up PR.
@@ -358,6 +353,17 @@ protected Clock getClock() { | |||
return Collections.singletonList(new SecurityUsageServices(null, null, null, null)); | |||
} | |||
|
|||
// We need to construct the checks here while the secure settings are still available. | |||
// If we want until #getBoostrapChecks the secure settings will have been cleared/closed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: want -> wait
@@ -225,14 +232,16 @@ public Settings additionalSettings() { | |||
NodeEnvironment nodeEnvironment, NamedWriteableRegistry namedWriteableRegistry) { | |||
List<Object> components = new ArrayList<>(); | |||
|
|||
final SSLService sslService = new SSLService(environment); | |||
setSslService(sslService); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: this looks like the only use of setSslService, can it be removed and just set the setonce member directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LocalStateCompositeXPackPlugin
does crazy stuff.
This is the only use of the method, but we have multiple implementations :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Makes sense to me to initialize the SSLService
with the Environment
instance most of the other components use (apart from the PlugingService
), and because security
depends on x-pack-core
the SSLService
will always be created on the latter's createComponents
, before it is referenced in the former's factory methods.
This removes the old `SSLService(Settings, Environment)` constructor and converts all uses cases to the `SSLService(Environment)` constructor that was added in elastic#49667
XPackPlugin created an SSLService within the plugin contructor. This has 2 negative consequences: 1. The service may be constructed based on a partial view of settings. Other plugins are free to add setting values via the additionalSettings() method, but this (necessarily) happens after plugins have been constructed. 2. Any exceptions thrown during the plugin construction are handled differently than exceptions thrown during "createComponents". Since SSL configurations exceptions are relatively common, it is far preferable for them to be thrown and handled as part of the createComponents flow. This commit moves the creation of the SSLService to XPackPlugin.createComponents, and alters the sequence of some other steps to accommodate this change. Relates: elastic#44536 Backport of: elastic#49667
XPackPlugin created an SSLService within the plugin contructor. This has 2 negative consequences: 1. The service may be constructed based on a partial view of settings. Other plugins are free to add setting values via the additionalSettings() method, but this (necessarily) happens after plugins have been constructed. 2. Any exceptions thrown during the plugin construction are handled differently than exceptions thrown during "createComponents". Since SSL configurations exceptions are relatively common, it is far preferable for them to be thrown and handled as part of the createComponents flow. This commit moves the creation of the SSLService to XPackPlugin.createComponents, and alters the sequence of some other steps to accommodate this change. Backport of: #49667
This removes the old `SSLService(Settings, Environment)` constructor and converts all uses cases to the `SSLService(Environment)` constructor that was added in #49667
XPackPlugin created an SSLService within the plugin contructor. This has 2 negative consequences: 1. The service may be constructed based on a partial view of settings. Other plugins are free to add setting values via the additionalSettings() method, but this (necessarily) happens after plugins have been constructed. 2. Any exceptions thrown during the plugin construction are handled differently than exceptions thrown during "createComponents". Since SSL configurations exceptions are relatively common, it is far preferable for them to be thrown and handled as part of the createComponents flow. This commit moves the creation of the SSLService to XPackPlugin.createComponents, and alters the sequence of some other steps to accommodate this change. Relates: elastic#44536
This removes the old `SSLService(Settings, Environment)` constructor and converts all uses cases to the `SSLService(Environment)` constructor that was added in elastic#49667
XPackPlugin created an SSLService within the plugin contructor.
This has 2 negative consequences:
The service may be constructed based on a partial view of settings.
Other plugins are free to add setting values via the
additionalSettings() method, but this (necessarily) happens after
plugins have been constructed.
Any exceptions thrown during the plugin construction are handled
differently than exceptions thrown during "createComponents".
Since SSL configurations exceptions are relatively common, it is
far preferable for them to be thrown and handled as part of the
createComponents flow.
This commit moves the creation of the SSLService to
XPackPlugin.createComponents, and alters the sequence of some other
steps to accommodate this change.
Relates: #44536