-
Notifications
You must be signed in to change notification settings - Fork 73
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
[Extensions] Renames AD extension routes to NamedRoutes #942
[Extensions] Renames AD extension routes to NamedRoutes #942
Conversation
…lers to use new handler signature from SDK Signed-off-by: Darshit Chanpura <[email protected]>
CI will be unblocked once opensearch-project/opensearch-sdk-java#827 is merged and an artifact is available. |
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.
LGTM except we don't use star imports (if spotless isn't failing we should make it do so!) and the base URI is "detectors" so the named route should match.
src/main/java/org/opensearch/ad/rest/RestPreviewAnomalyDetectorAction.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opensearch/ad/rest/RestDeleteAnomalyResultsAction.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Darshit Chanpura <[email protected]>
@dbwiddis The terms "detector/" and "detectors/" seem to be used interchangeably. I've updated the changes to reflect uri for base detectors, but it could be standardized if needed. |
Codecov Report
@@ Coverage Diff @@
## feature/extensions #942 +/- ##
========================================================
- Coverage 42.86% 42.79% -0.07%
- Complexity 2420 2421 +1
========================================================
Files 301 301
Lines 18169 18203 +34
Branches 1873 1873
========================================================
+ Hits 7788 7790 +2
- Misses 9806 9839 +33
+ Partials 575 574 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Signed-off-by: Darshit Chanpura <[email protected]>
CI will pass once opensearch-project/opensearch-sdk-java#868 is merged and an artifact is available. |
@DarshitChanpura can you provide an example of the new URl for ad-extension for let's say create detector? Let's add it in the PR description. |
@@ -105,7 +106,7 @@ public List<ReplacedRouteHandler> replacedRouteHandlers() { | |||
); | |||
} | |||
|
|||
private Function<RestRequest, ExtensionRestResponse> handleRequest = (request) -> { | |||
private Function<RestRequest, RestResponse> handleRequest = (request) -> { |
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.
Trying to understand why are we changing the response type from ExtensionRestResponse
to RestResponse
?
If this is coming from NameRoute then we should change the return type of prepareRequest
to RestResponse
as well?
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.
NamedRoute is available to both plugins and extensions, and hence RestResponse instead of ExtensionRestResponse (which inherits RestResponse transitively). prepareRequest should still return ExtensionRestResponse as it is one of the concrete implementation of RestResponse
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.
On line 71
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.
prepareRequest should still return ExtensionRestResponse as it is one of the concrete implementations of RestResponse and will be interpreted as such when send the response back to user. However, the only use case I see for ExtensionRestResponse is for communication between OS and extension to mark that the content was consumed and a list of consumed content.
@dbwiddis had some thoughts on whether we should keep ExtensionRestResponse or just use BytesRestReponse class
I've updated the description. |
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.
LGTM! Thanks for addressing comments
Closing this until the work is resumed. |
Description
As part of an ongoing effort to introduce authorization in REST layer, a concept of NamedRoute was introduced in core. A NamedRoute provides cluster admins an ability to grant/revoke access to specific endpoints in a cluster. This is introduced as an optional feature for plugins, and a mandatory feature for extensions since they don't interact with the cluster at transport layer and so the only way to authorize these requests would be at REST layer. To enforce all routes to be NamedRoute, a change was made in SDK: opensearch-project/opensearch-sdk-java#827 to enforce declaring new routes as NamedRoute.
This PR introduces changes that conform to the changes introduced in SDK.
Example
Consider this url for example:
POST /detectors/{detectorId}/profile
This route will now be registered with a route named:
ad:detectors/profile
consideringrouteNamePrefix
value in settings.yml is set toad
.Consider this role:
And says user X is mapped to this role. Now there are two possible use cases:
Without Security: No change.
With Security:
a. Once [Backport 2.x] Authorize rest requests (#2753) and Enhance RestLayerPrivilegesEvaluator Code Coverage (#3218) security#2956 is merged and released for 2.9, cluster admins can now permission these routes as if they were granting cluster_permission to a transport action. This will be evaluated at REST layer inside security plugin. For the given example, user X will be evaluated against the route
/detectors/{detectorId}/profile
which is mapped to namead:detectors/profile
, and since user X is mapped to a rolead_role
which contains this permission, the user will be successfully evaluated and the request chain will proceed. On other hand, if user was not mapped to this role or if there was a typo mapping the role, the evaluation would fail with 401.b. If [Backport 2.x] Authorize rest requests (#2753) and Enhance RestLayerPrivilegesEvaluator Code Coverage (#3218) security#2956 does not get released in 2.9 due to internal reviews not being complete on time, then there will not be any change in the way authorization works. It will be business as usual.
Issues Resolved
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.