[Extensions] Renames AD extension routes to NamedRoutes#942
[Extensions] Renames AD extension routes to NamedRoutes#942DarshitChanpura wants to merge 3 commits intoopensearch-project:feature/extensionsfrom
Conversation
…lers to use new handler signature from SDK Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
|
CI will be unblocked once opensearch-project/opensearch-sdk-java#827 is merged and an artifact is available. |
dbwiddis
left a comment
There was a problem hiding this comment.
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 <dchanp@amazon.com>
|
@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 <dchanp@amazon.com>
|
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. |
| } | ||
|
|
||
| private Function<RestRequest, ExtensionRestResponse> handleRequest = (request) -> { | ||
| private Function<RestRequest, RestResponse> handleRequest = (request) -> { |
There was a problem hiding this comment.
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.
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.
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. |
owaiskazi19
left a comment
There was a problem hiding this comment.
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}/profileThis route will now be registered with a route named:
ad:detectors/profileconsideringrouteNamePrefixvalue 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}/profilewhich is mapped to namead:detectors/profile, and since user X is mapped to a rolead_rolewhich 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.