You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem?
As part of #522 we are supporting enhanced monitor configs which can be provided by the client plugins (such as Security Analytics) allowing more control over various configurations which are held by the monitor object. These configurations help define the input and output index sources for monitors allowing data isolation within the monitors. These are optional params which users of the plugins (such as Security Analytics) can use to injects their own configurations such as source data, query index, findings index etc. helping with separation of concerns in data layer for Alerting Plugin.
However, we also need to have identification and segregation of the Monitors on the Alerting plugin side. This will help identify who is the correct owner of the monitors (such as SAP, AD vs Alerting), and hence Alerting APIs and visualization can safely skip attributing to such monitors as part of their Alerting flow.
There are two possible ways to achieve it:
Provide Index Isolation : Each client plugin, such as Security Analytics, can provide its own Index name for persisting the monitor configurations. This means separate index per client plugin. This although maintains the data isolation at a higher level, managing multiple indices could be a maintenance overhead, without clear ownership of the index lifecycle management.
Provide Document Isolation (Recommended): Each monitor object in the monitor config owner by the Alerting can have a owner field, which could allow trace back its origin. Absence of the field could be treated as as default/fallback where Alerting becomes the owner. The Alerting Get APIs could attribute to the field value and filter on the documents while returning responses.
+1 on using an owner field for multi-tenancy as monitor index is maintained by alerting unlike the custom datasources such as query, alerts, findings indices which can be created/modified/deleted by the plugins.
Is your feature request related to a problem?
As part of #522 we are supporting enhanced monitor configs which can be provided by the client plugins (such as Security Analytics) allowing more control over various configurations which are held by the monitor object. These configurations help define the input and output index sources for monitors allowing data isolation within the monitors. These are optional params which users of the plugins (such as Security Analytics) can use to injects their own configurations such as source data, query index, findings index etc. helping with separation of concerns in data layer for Alerting Plugin.
However, we also need to have identification and segregation of the
Monitors
on the Alerting plugin side. This will help identify who is the correct owner of the monitors (such as SAP, AD vs Alerting), and hence Alerting APIs and visualization can safely skip attributing to such monitors as part of their Alerting flow.There are two possible ways to achieve it:
Provide Index Isolation : Each client plugin, such as Security Analytics, can provide its own Index name for persisting the monitor configurations. This means separate index per client plugin. This although maintains the data isolation at a higher level, managing multiple indices could be a maintenance overhead, without clear ownership of the index lifecycle management.
Provide Document Isolation (Recommended): Each monitor object in the monitor config owner by the Alerting can have a
owner
field, which could allow trace back its origin. Absence of the field could be treated as as default/fallback where Alerting becomes the owner. The Alerting Get APIs could attribute to the field value and filter on the documents while returning responses.cc: @eirsep @sbcd90 @lezzago
The text was updated successfully, but these errors were encountered: