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

[ML] prefer secondary auth headers on data frame analytics _explain #63281

Conversation

benwtrent
Copy link
Member

We should prefer secondary auth headers when calling _explain

@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core (:ml)

@benwtrent benwtrent force-pushed the feature/ml-use-secondary-headers-on-explain branch from 05da590 to f8d27a8 Compare October 5, 2020 19:44
);
if (licenseState.isSecurityEnabled()) {
useSecondaryAuthIfAvailable(this.securityContext, () -> {
// Use secondary auth headers for the request always
Copy link
Contributor

Choose a reason for hiding this comment

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

What does "always" mean in this context? We're in the conditional branch, that's why I'm asking.

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 means in preference to headers that might already be stored on the data frame analytics config, if it came from the config index rather than being supplied in the explain request. The comment should say something like this.

So this means that if Alice tries to explain a pre-existing data frame analytics job created by Bob then that explanation will use Alice's credentials to access the source indices instead of Bob's. Before this change it would have used Bob's, which is superficially analogous to what what would have happened if Alice had started the job that Bob created. However, in the case of Alice starting Bob's job the outputs would go to the destination indices, which presumably Bob owns. If Bob has chosen not to give access to Alice then Alice cannot see the results. In the case of explain, Alice gets to see the results directly in the JSON response, so it makes more sense to use her credentials to access the source indices.


private static String basicAuth(String user) {
return UsernamePasswordToken.basicAuthHeaderValue(user, SecuritySettingsSourceField.TEST_PASSWORD_SECURE_STRING);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: new line after end of method

Co-authored-by: Przemysław Witek <przemyslaw.witek@elastic.co>
Copy link
Contributor

@dimitris-athanasiou dimitris-athanasiou left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@przemekwitek przemekwitek left a comment

Choose a reason for hiding this comment

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

LGTM

@benwtrent benwtrent merged commit 025b741 into elastic:master Oct 6, 2020
@benwtrent benwtrent deleted the feature/ml-use-secondary-headers-on-explain branch October 6, 2020 12:36
benwtrent added a commit to benwtrent/elasticsearch that referenced this pull request Oct 6, 2020
…lastic#63281)

We should prefer secondary auth headers when calling _explain
benwtrent added a commit that referenced this pull request Oct 6, 2020
…63281) (#63323)

We should prefer secondary auth headers when calling _explain
@tylersmalley
Copy link
Contributor

I believe this PR has caused an incompatibility with Kibana which is being tracked here.

I am not familiar enough with the code to understand if this issue is something that the ML team needs to address in the Kibana repository, or it's something that needs to be addressed here. Either way, I have also raised in the machine-learning channel.

It's pretty important that we resolve this quickly, as this incompatibility will prevent us from branching for 7.10.

@tylersmalley
Copy link
Contributor

This is being resolved on the Kibana side here.

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.

7 participants