Merge pull request #15 from opendistro/master

merge

Author: ashwinkumar12345

docs/ad/api.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Anomaly Detection
-nav_order: 36
+nav_order: 46
 has_children: true
 ---
 

docs/ad/index.md

@@ -0,0 +1,86 @@
+---
+layout: default
+title: Anomaly Detection Security
+nav_order: 10
+parent: Anomaly Detection
+has_children: false
+---
+
+# Anomaly detection security
+
+You can use the security plugin with anomaly detection to limit non-admin users to specific actions. For example, you might want some users to only be able to create, update, or delete detectors, while others to only view detectors.
+
+All anomaly detection indices are protected as system indices. Only a super admin user or an admin user with a TLS certificate can access system indices. For more information, see [System indices](../../security/configuration/system-indices/).
+
+
+Security for anomaly detection works the same as [security for alerting](../../alerting/security/).
+
+## Basic permissions
+
+As an admin user, you can use the security plugin to assign specific permissions to users based on which APIs they need access to. For a list of supported APIs, see [Anomaly Detection API](../api/).
+
+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](../../security/access-control/users-roles/#predefined-roles).
+
+If these roles don't meet your needs, mix and match individual anomaly detection [permissions](../../security/access-control/permissions/) to suit your use case. Each action corresponds to an operation in the REST API. For example, the `cluster:admin/opendistro/ad/detector/delete` permission lets you delete detectors.
+
+## (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.
+
+First, make sure that your users have the appropriate [backend roles](../../security/access-control/). Backend roles usually come from an [LDAP server](../../security/configuration/ldap/) or [SAML provider](../../security/configuration/saml/), but if you use the internal user database, you can use the REST API to [add them manually](../../security/access-control/api/#create-user).
+
+Next, enable the following setting:
+
+```json
+PUT _cluster/settings
+{
+  "transient": {
+    "opendistro.anomaly_detection.filter_by_backend_roles": "true"
+  }
+}
+```
+
+Now when users view anomaly detection resources in Kibana (or make REST API calls), they only see detectors created by users who share at least one backend role.
+For example, consider two users: `alice` and `bob`.
+
+`alice` has an analyst backend role:
+
+```json
+PUT _opendistro/_security/api/internalusers/alice
+{
+  "password": "alice",
+  "backend_roles": [
+    "analyst"
+  ],
+  "attributes": {}
+}
+```
+
+`bob` has a human-resources backend role:
+
+```json
+PUT _opendistro/_security/api/internalusers/bob
+{
+  "password": "bob",
+  "backend_roles": [
+    "human-resources"
+  ],
+  "attributes": {}
+}
+```
+
+Both `alice` and `bob` have full access to anomaly detection:
+
+```json
+PUT _opendistro/_security/api/rolesmapping/anomaly_full_access
+{
+  "backend_roles": [],
+  "hosts": [],
+  "users": [
+    "alice",
+    "bob"
+  ]
+}
+```
+
+Because they have different backend roles, `alice` and `bob` cannot view each other's detectors and its results.

docs/ad/security.md

@@ -0,0 +1,38 @@
+---
+layout: default
+title: Settings
+parent: Anomaly Detection
+nav_order: 4
+---
+
+# Settings
+
+The anomaly detection plugin adds several settings to the standard Elasticsearch cluster settings.
+They are dynamic, so you can change the default behavior of the plugin without restarting your cluster.
+You can mark them `persistent` or `transient`.
+
+For example, to update the retention period of the result index:
+
+```json
+PUT _cluster/settings
+{
+  "transient": {
+    "opendistro.anomaly_detection.ad_result_history_retention_period": "5m"
+  }
+}
+```
+
+Setting | Default | Description
+:--- | :--- | :---
+`opendistro.anomaly_detection.enabled` | True | Whether the anomaly detection plugin is enabled or not. If disabled, all detectors immediately stop running.
+`opendistro.anomaly_detection.max_anomaly_detectors` | 1,000 | The maximum number of non-high cardinality detectors (no category field) users can create.
+`opendistro.anomaly_detection.max_multi_entity_anomaly_detectors` | 10 | The maximum number of high cardinality detectors (with category field) in a cluster.
+`opendistro.anomaly_detection.max_anomaly_features` | 5 | The maximum number of features for a detector.
+`opendistro.anomaly_detection.ad_result_history_rollover_period` | 12h | How often the rollover condition is checked. If `true`, the plugin rolls over the result index to a new index.
+`opendistro.anomaly_detection.ad_result_history_max_docs` | 250000000 | The maximum number of documents in one result index. The plugin only counts refreshed documents in the primary shards.
+`opendistro.anomaly_detection.ad_result_history_retention_period` | 30d | The maximum age of the result index.  If its age exceeds the threshold, the plugin deletes the rolled over result index. If the cluster has only one result index, the plugin keeps it even if it's older than its configured retention period.
+`opendistro.anomaly_detection.max_entities_per_query` | 1,000 | The maximum unique values per detection interval for high cardinality detectors. By default, if the category field has more than 1,000 unique values in a detector interval, the plugin selects the top 1,000 values and orders them by `doc_count`.
+`opendistro.anomaly_detection.max_entities_for_preview` | 30 | The maximum unique category field values displayed with the preview operation for high cardinality detectors. If the category field has more than 30 unique values, the plugin selects the top 30 values and orders them by `doc_count`.
+`opendistro.anomaly_detection.max_primary_shards` | 10 | The maximum number of primary shards an anomaly detection index can have.
+`opendistro.anomaly_detection.filter_by_backend_roles` | False | When you enable the security plugin and set this to `true`, the plugin filters results based on the user's backend role(s).
+`opendistro.anomaly_detection.max_cache_miss_handling_per_second` | 100 | High cardinality detectors use a cache to store active models. In the event of a cache miss, the cache gets the models from the model checkpoint index. Use this setting to limit the rate of fetching models. Because the thread pool for a GET operation has a queue of 1,000, we recommend setting this value below 1,000.

docs/ad/settings.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Alerting
-nav_order: 30
+nav_order: 34
 has_children: true
 ---
 

docs/alerting/index.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Index State Management
-nav_order: 34
+nav_order: 30
 has_children: true
 ---
 

docs/images/ad.png

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: KNN
-nav_order: 34
+nav_order: 50
 has_children: true
 has_toc: false
 ---
@@ -202,7 +202,7 @@ All parameters are required.
 - `source` is the name of the script, `knn_score`.
 
   This script is part of the KNN plugin and isn't available at the standard `_scripts` path. A GET request to  `_cluster/state/metadata` doesn't return it, either.
-  
+
 - `field` is the field that contains your vector data.
 - `vector` is the point you want to find the nearest neighbors for.
 - `space_type` is either `l2` or `cosinesimil`.

docs/ism/index.md

@@ -1,11 +1,14 @@
 ---
 layout: default
-title: Notebooks
-nav_order: 38
+title: Notebooks (experimental)
+nav_order: 54
 has_children: false
 ---
 
-# Kibana Notebooks
+# Kibana notebooks (experimental)
+
+Kibana notebooks have a known issue with [tenants](../security/access-control/multi-tenancy/). If you open a notebook and can't see its visualizations, you might be under the wrong tenant, or you might not have access to the tenant at all.
+{: .warning }
 
 A Kibana notebook is an interface that lets you easily combine live visualizations and narrative text in a single notebook interface.
 
@@ -15,6 +18,7 @@ A notebook is a document composed of two elements: Kibana visualizations and par
 
 Common use cases include creating postmortem reports, designing runbooks, building live infrastructure reports, and writing documentation.
 
+
 ## Get Started with Notebooks
 
 To get started, choose **Kibana Notebooks** in Kibana.

docs/knn/index.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Performance Analyzer
-nav_order: 38
+nav_order: 58
 has_children: true
 ---