Is your feature request related to a problem?
User can create a detector on indicies on which he doesn't have an access rights
What solution would you like?
Detector creation flow should notify a user that he can't create a detector on the index for which he doesn't have a privilege.
What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.
Do you have any additional context?
During the detector creation flow, the context is being stashed at the begging of the operation (after system indicies are being initialized). Because of the stashing the context, the program continues with it's execution and behaves like an admin - which means that the user will be able to create a detector. Later on, automatically, the monitors will be created based on the given inputs, even user doesn't have a privileges over the given index.
The test that confirms this behavior:
- create a user which can access to windows* indices (userWithAccess) and a user which can access to test* indicies (userWithoutAccess)
- as a userWithAccess create a detector for the windows* indices and verify that the detector is created
- as a userWithoutAccess create a detector for the windows* indicies and verify that the detector is created
Link to a test branch:
test index access
Expected behavior:
- userWithoutAccess should be prevented from detector creation
In order to resolve this "issue" there are couple of approaches we can use.
Approach 1: Remove context stash
https://github.com/opensearch-project/security-analytics/blob/main/src/main/java/org/opensearch/securityanalytics/transport/TransportIndexDetectorAction.java#L599
General idea of this approach is to let the alerting to handle the security - ie. alerting should throw an error saying that the user (since we stashed the context) can't access the given indices.
If stashing of the context is removed, then the original user will be sent to alerting - but the thing is that before the monitor creation is being called on alerting, the request will fail because the given user is lacking system index privileges ie.
no permissions for [indices:data/read/search] -> user has an access to a given index pattern (test*) and can't access system index
Approach 2: Before detector creation, check if user can access a given indicies by executing a "dummy search":
https://github.com/stevanbz/security-analytics/blob/check-index-access-on-detector-creation/src/main/java/org/opensearch/securityanalytics/transport/TransportIndexDetectorAction.java#L186-L207
With this approach we would probably need to extend the list of privileges of the SECURITY_ANALYTICS_FULL_ACCESS_ROLE role to consider: indices:data/read/search index privilege
while the place for the privilege list extension:
https://github.com/opensearch-project/security/pull/2225/files#diff-46623c3b1c2fdee14837e52fcce0d6a65a13845f5e0460af67a2d92ab3c546d9R284-R286
Decision is made to go with the approach 2
Is your feature request related to a problem?
User can create a detector on indicies on which he doesn't have an access rights
What solution would you like?
Detector creation flow should notify a user that he can't create a detector on the index for which he doesn't have a privilege.
What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.
Do you have any additional context?
During the detector creation flow, the context is being stashed at the begging of the operation (after system indicies are being initialized). Because of the stashing the context, the program continues with it's execution and behaves like an admin - which means that the user will be able to create a detector. Later on, automatically, the monitors will be created based on the given inputs, even user doesn't have a privileges over the given index.
The test that confirms this behavior:
Link to a test branch:
test index access
Expected behavior:
In order to resolve this "issue" there are couple of approaches we can use.
Approach 1: Remove context stash
https://github.com/opensearch-project/security-analytics/blob/main/src/main/java/org/opensearch/securityanalytics/transport/TransportIndexDetectorAction.java#L599
General idea of this approach is to let the alerting to handle the security - ie. alerting should throw an error saying that the user (since we stashed the context) can't access the given indices.
If stashing of the context is removed, then the original user will be sent to alerting - but the thing is that before the monitor creation is being called on alerting, the request will fail because the given user is lacking system index privileges ie.
no permissions for [indices:data/read/search] -> user has an access to a given index pattern (test*) and can't access system index
Approach 2: Before detector creation, check if user can access a given indicies by executing a "dummy search":
https://github.com/stevanbz/security-analytics/blob/check-index-access-on-detector-creation/src/main/java/org/opensearch/securityanalytics/transport/TransportIndexDetectorAction.java#L186-L207
With this approach we would probably need to extend the list of privileges of the SECURITY_ANALYTICS_FULL_ACCESS_ROLE role to consider: indices:data/read/search index privilege
while the place for the privilege list extension:
https://github.com/opensearch-project/security/pull/2225/files#diff-46623c3b1c2fdee14837e52fcce0d6a65a13845f5e0460af67a2d92ab3c546d9R284-R286
Decision is made to go with the approach 2