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

Implement new extension points in IdentityPlugin and add ContextProvidingPluginSubject #4896

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

cwperks
Copy link
Member

@cwperks cwperks commented Nov 11, 2024

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 using pluginSystemSubject.runAs(() -> { ... }). See ./gradlew integrationTest --tests SystemIndexTests for an example that verifies that a block of code run with pluginSystemSubject.runAs(() -> { ... }) has contextual info in the thread context.

  • Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)

Enhancement

Issues Resolved

Related to #4439

Check List

  • New functionality includes testing
  • New functionality has been documented
  • New Roles/Permissions have a corresponding security dashboards plugin PR
  • API changes companion pull request created
  • Commits are signed per the DCO using --signoff

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.

Signed-off-by: Craig Perkins <[email protected]>
Signed-off-by: Craig Perkins <[email protected]>
Signed-off-by: Craig Perkins <[email protected]>
Copy link

codecov bot commented Nov 12, 2024

Codecov Report

Attention: Patch coverage is 84.52381% with 13 lines in your changes missing coverage. Please review.

Project coverage is 71.48%. Comparing base (4aa7b1c) to head (c25e1ab).

Files with missing lines Patch % Lines
...ensearch/security/privileges/ActionPrivileges.java 63.63% 5 Missing and 3 partials ⚠️
...earch/security/identity/PluginContextSwitcher.java 71.42% 2 Missing ⚠️
...ava/org/opensearch/security/auth/SecurityUser.java 90.00% 1 Missing ⚠️
...ecurity/privileges/SystemIndexAccessEvaluator.java 92.85% 0 Missing and 1 partial ⚠️
...c/main/java/org/opensearch/security/user/User.java 0.00% 0 Missing and 1 partial ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #4896      +/-   ##
==========================================
+ Coverage   71.41%   71.48%   +0.06%     
==========================================
  Files         334      337       +3     
  Lines       22515    22595      +80     
  Branches     3585     3596      +11     
==========================================
+ Hits        16080    16151      +71     
- Misses       4643     4648       +5     
- Partials     1792     1796       +4     
Files with missing lines Coverage Δ
.../opensearch/security/OpenSearchSecurityPlugin.java 84.37% <100.00%> (+0.36%) ⬆️
.../org/opensearch/security/auth/BackendRegistry.java 78.52% <100.00%> (+0.47%) ⬆️
...org/opensearch/security/filter/SecurityFilter.java 66.66% <100.00%> (+0.78%) ⬆️
...curity/identity/ContextProvidingPluginSubject.java 100.00% <100.00%> (ø)
...earch/security/privileges/PrivilegesEvaluator.java 73.96% <100.00%> (+0.31%) ⬆️
...g/opensearch/security/support/ConfigConstants.java 95.23% <ø> (ø)
...ava/org/opensearch/security/auth/SecurityUser.java 90.00% <90.00%> (ø)
...ecurity/privileges/SystemIndexAccessEvaluator.java 76.92% <92.85%> (+1.72%) ⬆️
...c/main/java/org/opensearch/security/user/User.java 69.41% <0.00%> (-0.83%) ⬇️
...earch/security/identity/PluginContextSwitcher.java 71.42% <71.42%> (ø)
... and 1 more

... and 2 files with indirect coverage changes

Set<String> clusterActions = new HashSet<>();
clusterActions.add(BulkAction.NAME);
PluginSubject subject = new ContextProvidingPluginSubject(threadPool, settings, plugin);
sf.updatePluginToClusterAction(subject.getPrincipal().getName(), clusterActions);
Copy link
Collaborator

@nibix nibix Nov 16, 2024

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants