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

Mandate X-Pack REST handler installed #71061

Merged
merged 30 commits into from
Jun 10, 2021

Conversation

BigPandaToo
Copy link
Contributor

@BigPandaToo BigPandaToo commented Mar 30, 2021

In order to provide a stronger guarantee to our solutions, that if a
cluster is running the default distribution and has security
(authentication) enabled,
then it will be provided by Elastic's security features, and users can
rely on it behaving in the ways they expect, this change mandate
that security in default distribution is provided by X-Pack by always
installing the Security Rest Filter.

Related: #70523

@BigPandaToo BigPandaToo requested review from ywangd and tvernum and removed request for ywangd March 30, 2021 14:00
@BigPandaToo BigPandaToo added v8.0.0 :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) labels Mar 30, 2021
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Mar 30, 2021
@elasticmachine
Copy link
Collaborator

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

@BigPandaToo
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/bwc

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also need to fill in the PR description

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo BigPandaToo requested a review from tvernum April 20, 2021 15:15
@tvernum
Copy link
Contributor

tvernum commented May 14, 2021

@BigPandaToo Can you please fill in the PR description.

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo BigPandaToo requested review from tvernum and ywangd June 3, 2021 12:30
Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

A few nits and also I don't particular like the "unit test". But they don't need to block this PR. Thanks!

Comment on lines +444 to +445
if (plugin.getClass().getCanonicalName() == null ||
plugin.getClass().getCanonicalName().startsWith("org.elasticsearch.xpack") == false) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I probably missed the discussion about why we prefer getCanonicalName over just getName here. But it seems to me that getName is more consistent since that is what we report in the error message (and also the debug log above)?

Comment on lines 446 to 447
logger.error("The " + plugin.getClass().getName() + " plugin tried to install a custom REST wrapper. This " +
"functionality is not available anymore.");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Since an exception is thrown immediately after this and will be logged. It seems this logging is no longer necessary.

Comment on lines 1122 to 1126
boolean extractClientCertificate = false;
if (enabled && HTTP_SSL_ENABLED.get(settings)) {
final SSLConfiguration httpSSLConfig = getSslService().getHttpTransportSSLConfiguration();
extractClientCertificate = getSslService().isSSLClientAuthEnabled(httpSSLConfig);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: we can save the extra finalExtractClientCertificate variable.

Suggested change
boolean extractClientCertificate = false;
if (enabled && HTTP_SSL_ENABLED.get(settings)) {
final SSLConfiguration httpSSLConfig = getSslService().getHttpTransportSSLConfiguration();
extractClientCertificate = getSslService().isSSLClientAuthEnabled(httpSSLConfig);
}
final boolean extractClientCertificate;
if (enabled && HTTP_SSL_ENABLED.get(settings)) {
final SSLConfiguration httpSSLConfig = getSslService().getHttpTransportSSLConfiguration();
extractClientCertificate = getSslService().isSSLClientAuthEnabled(httpSSLConfig);
} else {
extractClientCertificate = false;
}

@@ -514,6 +529,81 @@ public void testLicenseUpdateFailureHandlerUpdate() throws Exception {
}
}

public void testSecurityHandlerIsAlwaysInstalled() throws IllegalAccessException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The check is now relaxed to be package name. Do you think it is worth to have more unit test like tests?
Technically, even with the previous check for exact class name, it is possible to have an unit test for ActionModule: Since ActionModule is in a different module and does not depend on xpack security, it is possible to create a stub org.elasticsearch.xpack.security.Security class in its test package and use that for the unit test.

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@elasticmachine
Copy link
Collaborator

merge conflict between base and head

"functionality is not available anymore.");
throw new IllegalArgumentException("The " + plugin.getClass().getName() + " plugin tried to install a custom REST " +
"wrapper. This functionality is not available anymore.");
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per #73329, there should be tests for this functionality in ActionModuleTests.
Core shouldn't rely on x-pack to do its testing for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved it to ActionModuleTests

}
}

public void test3rdPartyHandlerIsNotInstalled() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This belongs in ActionModuleTests, it's a testing the behaviour of ActionModule, so it shouldn't be here.

@@ -514,6 +529,81 @@ public void testLicenseUpdateFailureHandlerUpdate() throws Exception {
}
}

public void testSecurityHandlerIsAlwaysInstalled() throws IllegalAccessException {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's testing 2 things, and I think it would be better if they were split into

  1. testSecurityPluginInstallsRestHandlerWrapperEvenIfSecurityIsDisabled which can simply be a test that Security.getRestHandlerWrapper() returns non-null even when disabled.
  2. testSecurityRestHandlerWrapperCanBeInstalled() which tests that ActionModule doesn't reject the wrapper installed by security (essentially this test).

@BigPandaToo BigPandaToo requested a review from tvernum June 9, 2021 19:37
Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I have a couple of suggestions.

class SecPlugin implements ActionPlugin {
@Override
public UnaryOperator<RestHandler> getRestHandlerWrapper(ThreadContext threadContext) {
return handler -> new FakeHandler();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine - there's no need to change it, but it would have been fine to just make this a no-op operator.

Suggested change
return handler -> new FakeHandler();
return UnaryOperator.identity();

We really only care that the plugin returns something. We don't care what it does.

Comment on lines 538 to 542
ActionModule actionModule = new ActionModule(settingsModule.getSettings(),
TestIndexNameExpressionResolver.newInstance(threadPool.getThreadContext()),
settingsModule.getIndexScopedSettings(), settingsModule.getClusterSettings(), settingsModule.getSettingsFilter(),
threadPool, Arrays.asList(security), null, null, usageService, null);
actionModule.initRestHandlers(null);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this needed?
I think you can skip all the ActionModule part since this is a simple unit test on Security

@BigPandaToo BigPandaToo merged commit 3eea3fb into elastic:master Jun 10, 2021
tvernum added a commit to tvernum/elasticsearch that referenced this pull request Feb 7, 2022
In elastic#71061 we removed support for custom REST Handler Wrappers.

This change adds that information to the migration guide under the
"Plugin changes" section
elasticsearchmachine pushed a commit that referenced this pull request Feb 8, 2022
In #71061 we removed support for custom REST Handler Wrappers.

This change adds that information to the migration guide under the
"Plugin changes" section
tvernum added a commit to tvernum/elasticsearch that referenced this pull request Feb 8, 2022
In elastic#71061 we removed support for custom REST Handler Wrappers.

This change adds that information to the migration guide under the
"Plugin changes" section
tvernum added a commit to tvernum/elasticsearch that referenced this pull request Feb 8, 2022
In elastic#71061 we removed support for custom REST Handler Wrappers.

This change adds that information to the migration guide under the
"Plugin changes" section
elasticsearchmachine pushed a commit that referenced this pull request Feb 8, 2022
In #71061 we removed support for custom REST Handler Wrappers.

This change adds that information to the migration guide under the
"Plugin changes" section
elasticsearchmachine pushed a commit that referenced this pull request Feb 8, 2022
In #71061 we removed support for custom REST Handler Wrappers.

This change adds that information to the migration guide under the
"Plugin changes" section
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>breaking-java :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants