-
Notifications
You must be signed in to change notification settings - Fork 343
Optimize getFieldFilter to only return a predicate when index has FLS restrictions for user #5777
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
base: main
Are you sure you want to change the base?
Optimize getFieldFilter to only return a predicate when index has FLS restrictions for user #5777
Conversation
… restrictions for user Signed-off-by: Craig Perkins <cwperx@amazon.com>
Signed-off-by: Craig Perkins <cwperx@amazon.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5777 +/- ##
==========================================
+ Coverage 73.66% 73.74% +0.08%
==========================================
Files 438 438
Lines 26660 26654 -6
Branches 3939 3939
==========================================
+ Hits 19638 19655 +17
+ Misses 5148 5126 -22
+ Partials 1874 1873 -1
🚀 New features to boost your workflow:
|
|
Are there any hot thread dumps or profiling data available for cases where performance issues were observed? Would be curious to have a look at it. |
nibix
left a comment
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.
Approving. Yet, this only covers the case when no FLS protection is present at all. If there is only a single protected field, we get the old performance profile.
It might be worthwhile to have a closer look at the cause of the issues in order to be able to improve these scenarios as well.
I could take a look at that.
The main cause is lack of resiliency measures to the GET _mapping API so any optimization in security is only of marginal gain IMO. I believe I've identified an opportunity to de-dup indices with the same mappings in the cluster state (for example rolled over indices). FYI In core I tried also adding some resiliency measures for GET _mapping API:
I'm looking into a 3rd improvement in the core as well to cut the in-memory size of the cluster state by keeping a mapping pool. |
|
Example hot threads dump: |
Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
|
opensearch-project/OpenSearch#19803 |
Planning to fix that in #5815 |
Signed-off-by: Craig Perkins <cwperx@amazon.com>
| try { | ||
| indexHasRestrictions = dlsFlsValve.indexHasFlsRestrictions(index, ctx); | ||
| } catch (PrivilegesEvaluationException e) { | ||
| log.error("Error while evaluating FLS restrictions for {}", index, e); |
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.
should the exception be re-thrown?
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.
I moved this block into the try-catch
if (!indexHasRestrictions) {
return NOOP_FIELD_PREDICATE;
}
In the event of an error, it will use the existing field-level check which I think is sensible.
Signed-off-by: Craig Perkins <cwperx@amazon.com>
…perks/security into get-field-filter-optimization
Description
This is another optimization for GET _mapping calls when running with the security plugin. This PR is similar to #5752 and avoids calling
dlsFlsValve.isFieldAllowed(index, field, ctx)for indices without restrictions. With the changes in this PR, security will only return a predicate to filter fields on indices that have FLS restrictions for the current user.Enhancement
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.