Skip to content
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

Merged
merged 3 commits into from
Dec 17, 2019

Conversation

tvernum
Copy link
Contributor

@tvernum tvernum commented Nov 28, 2019

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: #44536

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
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (:Security/Network)

@tvernum
Copy link
Contributor Author

tvernum commented Nov 28, 2019

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.

Copy link
Member

@rjernst rjernst left a 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) {
Copy link
Member

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.

Copy link
Contributor Author

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.
Copy link
Member

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);
Copy link
Member

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?

Copy link
Contributor Author

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 :(

Copy link
Contributor

@albertzaharovits albertzaharovits left a 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.

@tvernum tvernum merged commit 046595d into elastic:master Dec 17, 2019
tvernum added a commit to tvernum/elasticsearch that referenced this pull request Dec 19, 2019
This removes the old `SSLService(Settings, Environment)` constructor
and converts all uses cases to the `SSLService(Environment)`
constructor that was added in elastic#49667
tvernum added a commit to tvernum/elasticsearch that referenced this pull request Dec 30, 2019
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
tvernum added a commit that referenced this pull request Dec 30, 2019
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
tvernum added a commit that referenced this pull request Jan 6, 2020
This removes the old `SSLService(Settings, Environment)` constructor
and converts all uses cases to the `SSLService(Environment)`
constructor that was added in #49667
SivagurunathanV pushed a commit to SivagurunathanV/elasticsearch that referenced this pull request Jan 23, 2020
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
SivagurunathanV pushed a commit to SivagurunathanV/elasticsearch that referenced this pull request Jan 23, 2020
This removes the old `SSLService(Settings, Environment)` constructor
and converts all uses cases to the `SSLService(Environment)`
constructor that was added in elastic#49667
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants