OpenSearch/x-pack/plugin/ml/qa/ml-with-security/roles.yml

minimal:
  cluster:
    # This is always required because the REST client uses it to find the version of
    # Elasticsearch it's talking to
    - cluster:monitor/main
  indices:
    # Give all users involved in these tests access to the indices where the data to
    # be analyzed is stored, because the ML roles alone do not provide access to
    # non-ML indices
    - names: [ 'airline-data', 'index-*', 'unavailable-data', 'utopia' ]
      privileges:
        - create_index
        - indices:admin/refresh
        - read
        - index
        - view_index_metadata
        - indices:data/write/bulk
        - indices:data/write/index
[ML] Add machine learning privileges/roles (elastic/x-pack-elasticsearch#673) * Changed ML action names to allow distinguishing of admin and read-only actions using wildcards * Added manage_ml and monitor_ml built-in privileges as subsets of the existing manage and monitor privileges * Added out-of-the-box machine_learning_admin and machine_learning_user roles * Changed machine learning results endpoints to use a NodeClient rather than an InternalClient when searching for results so that index/document level permissions applied to ML results are respected Original commit: elastic/x-pack-elasticsearch@eee800aaa8f20cefb084c813ec5eecbf42cde4cb 2017-03-14 16:13:41 +00:00			`minimal:`
			`cluster:`
[TEST] Improve ML security tests (elastic/x-pack-elasticsearch#2417) The changes made for elastic/x-pack-elasticsearch#2369 showed that the ML security tests were seriously weakened by the decision to grant many "minimal" privileges to all users involved in the tests. A better solution is to override the auth header such that a superuser runs setup actions and assertions that work by querying raw documents in ways that an end user wouldn't. Then the ML endpoints can be called with the privileges provided by the ML roles and nothing else. Original commit: elastic/x-pack-elasticsearch@4de42d9e547099f83589a59148f1f291858c01f7 2017-09-05 10:49:41 +01:00			`# This is always required because the REST client uses it to find the version of`
			`# Elasticsearch it's talking to`
[ML] Add machine learning privileges/roles (elastic/x-pack-elasticsearch#673) * Changed ML action names to allow distinguishing of admin and read-only actions using wildcards * Added manage_ml and monitor_ml built-in privileges as subsets of the existing manage and monitor privileges * Added out-of-the-box machine_learning_admin and machine_learning_user roles * Changed machine learning results endpoints to use a NodeClient rather than an InternalClient when searching for results so that index/document level permissions applied to ML results are respected Original commit: elastic/x-pack-elasticsearch@eee800aaa8f20cefb084c813ec5eecbf42cde4cb 2017-03-14 16:13:41 +00:00			`- cluster:monitor/main`
			`indices:`
[TEST] Improve ML security tests (elastic/x-pack-elasticsearch#2417) The changes made for elastic/x-pack-elasticsearch#2369 showed that the ML security tests were seriously weakened by the decision to grant many "minimal" privileges to all users involved in the tests. A better solution is to override the auth header such that a superuser runs setup actions and assertions that work by querying raw documents in ways that an end user wouldn't. Then the ML endpoints can be called with the privileges provided by the ML roles and nothing else. Original commit: elastic/x-pack-elasticsearch@4de42d9e547099f83589a59148f1f291858c01f7 2017-09-05 10:49:41 +01:00			`# Give all users involved in these tests access to the indices where the data to`
			`# be analyzed is stored, because the ML roles alone do not provide access to`
			`# non-ML indices`
[ML] Make datafeeds run-as the user who created/updated them (elastic/x-pack-elasticsearch#3254) This is the ML equivalent of what was done for Watcher in elastic/x-pack-elasticsearch#2808. For security reasons, ML datafeeds should not run as the _xpack user. Instead, they record the security headers from the request to create/update them, and reuse these when performing the search to retrieve data for analysis. Relates elastic/x-pack-elasticsearch#1071 Original commit: elastic/x-pack-elasticsearch@29f85de404a8afb26d9f43cfe1fbef103446ea5f 2017-12-11 13:01:16 +00:00			`- names: [ 'airline-data', 'index-*', 'unavailable-data', 'utopia' ]`
[ML] Add machine learning privileges/roles (elastic/x-pack-elasticsearch#673) * Changed ML action names to allow distinguishing of admin and read-only actions using wildcards * Added manage_ml and monitor_ml built-in privileges as subsets of the existing manage and monitor privileges * Added out-of-the-box machine_learning_admin and machine_learning_user roles * Changed machine learning results endpoints to use a NodeClient rather than an InternalClient when searching for results so that index/document level permissions applied to ML results are respected Original commit: elastic/x-pack-elasticsearch@eee800aaa8f20cefb084c813ec5eecbf42cde4cb 2017-03-14 16:13:41 +00:00			`privileges:`
Add auto create action (#56122) Backport of #55858 to 7.x branch. Currently the TransportBulkAction detects whether an index is missing and then decides whether it should be auto created. The coordination of the index creation also happens in the TransportBulkAction on the coordinating node. This change adds a new transport action that the TransportBulkAction delegates to if missing indices need to be created. The reasons for this change: * Auto creation of data streams can't occur on the coordinating node. Based on the index template (v2) either a regular index or a data stream should be created. However if the coordinating node is slow in processing cluster state updates then it may be unaware of the existence of certain index templates, which then can load to the TransportBulkAction creating an index instead of a data stream. Therefor the coordination of creating an index or data stream should occur on the master node. See #55377 * From a security perspective it is useful to know whether index creation originates from the create index api or from auto creating a new index via the bulk or index api. For example a user would be allowed to auto create an index, but not to use the create index api. The auto create action will allow security to distinguish these two different patterns of index creation. This change adds the following new transport actions: AutoCreateAction, the TransportBulkAction redirects to this action and this action will actually create the index (instead of the TransportCreateIndexAction). Later via #55377, can improve the AutoCreateAction to also determine whether an index or data stream should be created. The create_index index privilege is also modified, so that if this permission is granted then a user is also allowed to auto create indices. This change does not yet add an auto_create index privilege. A future change can introduce this new index privilege or modify an existing index / write index privilege. Relates to #53100 2020-05-04 19:10:09 +02:00			`- create_index`
[ML] Add machine learning privileges/roles (elastic/x-pack-elasticsearch#673) * Changed ML action names to allow distinguishing of admin and read-only actions using wildcards * Added manage_ml and monitor_ml built-in privileges as subsets of the existing manage and monitor privileges * Added out-of-the-box machine_learning_admin and machine_learning_user roles * Changed machine learning results endpoints to use a NodeClient rather than an InternalClient when searching for results so that index/document level permissions applied to ML results are respected Original commit: elastic/x-pack-elasticsearch@eee800aaa8f20cefb084c813ec5eecbf42cde4cb 2017-03-14 16:13:41 +00:00			`- indices:admin/refresh`
[7.x][ML] Machine learning data frame analytics (#43544) (#43592) This merges the initial work that adds a framework for performing machine learning analytics on data frames. The feature is currently experimental and requires a platinum license. Note that the original commits can be found in the `feature-ml-data-frame-analytics` branch. A new set of APIs is added which allows the creation of data frame analytics jobs. Configuration allows specifying different types of analysis to be performed on a data frame. At first there is support for outlier detection. The APIs are: - PUT _ml/data_frame/analysis/{id} - GET _ml/data_frame/analysis/{id} - GET _ml/data_frame/analysis/{id}/_stats - POST _ml/data_frame/analysis/{id}/_start - POST _ml/data_frame/analysis/{id}/_stop - DELETE _ml/data_frame/analysis/{id} When a data frame analytics job is started a persistent task is created and started. The main steps of the task are: 1. reindex the source index into the dest index 2. analyze the data through the data_frame_analyzer c++ process 3. merge the results of the process back into the destination index In addition, an evaluation API is added which packages commonly used metrics that provide evaluation of various analysis: - POST _ml/data_frame/_evaluate 2019-06-25 20:29:11 +03:00			`- read`
			`- index`
Add view_index_metadata to roles.yml and remove as many df analytics test cases from build.gradle blacklist as possible. (#45451) (#45465) 2019-08-13 08:31:58 +02:00			`- view_index_metadata`
[ML] Add machine learning privileges/roles (elastic/x-pack-elasticsearch#673) * Changed ML action names to allow distinguishing of admin and read-only actions using wildcards * Added manage_ml and monitor_ml built-in privileges as subsets of the existing manage and monitor privileges * Added out-of-the-box machine_learning_admin and machine_learning_user roles * Changed machine learning results endpoints to use a NodeClient rather than an InternalClient when searching for results so that index/document level permissions applied to ML results are respected Original commit: elastic/x-pack-elasticsearch@eee800aaa8f20cefb084c813ec5eecbf42cde4cb 2017-03-14 16:13:41 +00:00			`- indices:data/write/bulk`
			`- indices:data/write/index`