-
Notifications
You must be signed in to change notification settings - Fork 278
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
Implement new extension points in IdentityPlugin and add ContextProvidingPluginSubject #4896
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Craig Perkins <[email protected]>
Signed-off-by: Craig Perkins <[email protected]>
Signed-off-by: Craig Perkins <[email protected]>
Signed-off-by: Craig Perkins <[email protected]>
Signed-off-by: Craig Perkins <[email protected]>
Set<String> clusterActions = new HashSet<>(); | ||
clusterActions.add(BulkAction.NAME); | ||
PluginSubject subject = new ContextProvidingPluginSubject(threadPool, settings, plugin); | ||
sf.updatePluginToClusterAction(subject.getPrincipal().getName(), clusterActions); |
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.
In what life-cycle stage(s) will this method will be called in?
In the current state of the implementation, this method must be called very early, as the constructed ActionPrivileges
instance is immutable and will be only updated upon configuration change events. If this method gets called at the wrong time, changes won't be picked up immediately.
Additionaly, an open question is whether one has to think of concurrent calls or not.
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.
This is called during node bootstrap. Its called directly after createComponents
@@ -152,6 +154,7 @@ public class PrivilegesEvaluator { | |||
private DynamicConfigModel dcm; | |||
private final NamedXContentRegistry namedXContentRegistry; | |||
private final Settings settings; | |||
private final Map<String, Set<String>> pluginToClusterActions; |
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 guess, it is only a temporary state that we'll have cluster actions here?
If we get also index privileges and possibly other stuff soon, this certainly would deserve its own class encapsulating and managing the details. Then, one could also avoid this call delegation of updatePluginToClusterActions()
through SecurityFilter
which feels artificial.
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.
Yes, that's right. I made that chain of calls to updatePluginToClusterActions()
out of convenience, but it is less then ideal. I have a PR open in core to declare actions a plugin will perform with its identity and prompt on installation, but it is currently stalled.
I plan to take a little bit of time to see what it would take to move system index protection into the core and introduce a notion of admin certificate to the core as a mechanism for taking invasive action on system indices if required.
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.
The biggest challenge I see is ActionRequest -> concrete index resolution.
Signed-off-by: Craig Perkins <[email protected]>
Description
Re-opening this previously closed PR to rebase on top of Optimized Privilege Evaluation
Companion PR in core: opensearch-project/OpenSearch#14630
This PR by itself does not add additional functionality, it simply implements the new extension points in core and introduces a new class called
ContextProvidingPluginSubject
which populates a header in the ThreadContext with the canonical class name of the plugin that is executing code usingpluginSystemSubject.runAs(() -> { ... })
. See./gradlew integrationTest --tests SystemIndexTests
for an example that verifies that a block of code run withpluginSystemSubject.runAs(() -> { ... })
has contextual info in the thread context.Enhancement
Issues Resolved
Related to #4439
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.