Adding documentation for remote index use in AD

_observing-your-data/ad/index.md

@@ -29,9 +29,14 @@
 1. Add in the detector details.
    - Enter a name and brief description. Make sure the name is unique and descriptive enough to help you to identify the purpose of the detector.
 1. Specify the data source.   
-   - For **Data source**, choose the index you want to use as the data source. You can optionally use index patterns to choose multiple indexes.
+   - For **Data source**, choose the index or indexes you want to use as the data source. Alternatively, you can use an alias or index patterns to choose multiple indexes. 
+   - Detectors can use remote indexes. You can access them using the `cluster-name:index-name` pattern, as used in [cross-cluster search]({{site.url}}{{site.baseurl}}/search-plugins/cross-cluster-search/). Alternatively, you can select the clusters and indexes you want to use through OpenSearch Dashboards 2.17 or later. For more information about configuring remote indexes with the Security plugin enabled, you can view [here]({{site.url}}{{site.baseurl}}/observing-your-data/ad/security/#selecting-remote-indexes-with-fine-grained-access-control)
    - (Optional) For **Data filter**, filter the index you chose as the data source. From the **Data filter** menu, choose **Add data filter**, and then design your filter query by selecting **Field**, **Operator**, and **Value**, or choose **Use query DSL** and add your own JSON filter query. Only [Boolean queries]({{site.url}}{{site.baseurl}}/query-dsl/compound/bool/) are supported for query domain-specific language (DSL).
 
+
+To create a cross-cluster detector through OpenSearch Dashboards, the following [permissions]({{site.url}}{{site.baseurl}}/security/access-control/permissions/) are required: `indices:data/read/field_caps`, `indices:admin/resolve/index`, and `cluster:monitor/remote/info`.
+{: .note}
+
 #### Example filter using query DSL
 The query is designed to retrieve documents in which the `urlPath.keyword` field matches one of the following specified values:
 

_observing-your-data/ad/security.md

@@ -23,6 +23,11 @@ As an admin user, you can use the Security plugin to assign specific permissions
 
 The Security plugin has two built-in roles that cover most anomaly detection use cases: `anomaly_full_access` and `anomaly_read_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
 
+If you are using OpenSearch Dashboards to create your anomaly detectors you might notice issues creating a detector even with `anomaly_full_access`, this has been mitigated in OpenSearch 2.17. In order to mitigate this issue in prior versions, you should add these additional permissions:
+
+- `indices:data/read/search` - You need the search permission because the Anomaly Detection plugin needs to search the data source in order to validate if there is enough data to train the model.
+- `indices:admin/mappings/fields/get` and `indices:admin/mappings/fields/get*` - You need field mapping permissions since as part of detector creation we validate if the given data source has a valid timestamp field and categorical field (in case of creating a high cardinality detector)
+
 If these roles don't meet your needs, mix and match individual anomaly detection [permissions]({{site.url}}{{site.baseurl}}/security/access-control/permissions/) to suit your use case. Each action corresponds to an operation in the REST API. For example, the `cluster:admin/opensearch/ad/detector/delete` permission lets you delete detectors.
 
 ### A note on alerts and fine-grained access control
@@ -31,6 +36,36 @@ When a trigger generates an alert, the detector and monitor configurations, the
 
 To reduce the chances of unintended users viewing metadata that could describe an index, we recommend that administrators enable role-based access control and keep these kinds of design elements in mind when assigning permissions to the intended group of users. See [Limit access by backend role](#advanced-limit-access-by-backend-role) for details.
 
+
+### Selecting remote indexes with fine-grained access control
+
+In order to specify a remote index as the data source for a detector you must follow similar instruction as mentioned in the cross-cluster search [documentation]({{site.url}}{{site.baseurl}}/search-plugins/cross-cluster-search/#authentication-flow). By utilizing a role that exists in the both the remote and local cluster.The remote cluster will need to have the mapping between the chosen role and the same user name as in the local cluster. 
+
+For example:
+
+Create a new user on the local cluster from which you’ll create detectors from:
+
+```
+curl -XPUT -k -u 'admin:<custom-admin-password>' 'https://localhost:9200/_plugins/_security/api/internalusers/anomalyuser' -H 'Content-Type: application/json' -d '{"password":"password"}'
+```
+
+Map the new user to the anomaly_full_access role:
+
+```
+curl -XPUT -k -u 'admin:<custom-admin-password>' -H 'Content-Type: application/json' 'https://localhost:9200/_plugins/_security/api/rolesmapping/anomaly_full_access' -d '{"users" : ["anomalyuser"]}'
+```
+
+On the remote cluster, create the same user, and map anomaly_full_access to that role:
+
+```
+curl -XPUT -k -u 'admin:<custom-admin-password>' 'https://localhost:9250/_plugins/_security/api/internalusers/anomalyuser' -H 'Content-Type: application/json' -d '{"password":"password"}'
+curl -XPUT -k -u 'admin:<custom-admin-password>' -H 'Content-Type: application/json' 'https://localhost:9250/_plugins/_security/api/rolesmapping/anomaly_full_access' -d '{"users" : ["anomalyuser"]}'
+```
+
+### Custom result index
+
+In order to use a custom result index users will need to have additional permissions that aren't part of the default roles that OpenSearch Security plugin offers. Users will have to add additional permissions as mentioned in the custom result index set up step in [define detector]({{site.url}}{{site.baseurl}}/observing-your-data/ad/index/#step-1-define-a-detector).
+
 ## (Advanced) Limit access by backend role
 
 Use backend roles to configure fine-grained access to individual detectors based on roles. For example, users of different departments in an organization can view detectors owned by their own department.