OpenSearch/qa/smoke-test-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-foo', 'unavailable-data' ]
      privileges:
        - indices:admin/create
        - indices:admin/refresh
        - indices:data/read/field_caps
        - indices:data/read/search
        - 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`
			`- names: [ 'airline-data', 'index-foo', 'unavailable-data' ]`
[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:`
			`- indices:admin/create`
			`- indices:admin/refresh`
[ML] Automate detection of way to extract fields (elastic/x-pack-elasticsearch#1686) In 5.4.x, the datafeed attempts to get all fields from doc_values by default. It has a `_source` parameter which when enabled changes the strategy to instead try to get all fields from the source. This has been the most common issue users have been reporting as it means the datafeed will fail to fetch any text fields by default. This change uses the field capabilities API in order to automatically detect whether a field is aggregatable. It then extracts such fields from doc_values while the rest are taken from source. The change also adds validation to the start datafeed action so that if fields are missing mappings or the time field is not aggregatable we respond with an appropriate error. relates elastic/x-pack-elasticsearch#1649 Original commit: elastic/x-pack-elasticsearch@76e2cc6cb2c40aafc565af926d498b11066499ac 2017-06-12 14:56:31 +01:00			`- indices:data/read/field_caps`
[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/read/search`
			`- indices:data/write/bulk`
			`- indices:data/write/index`