2019-10-04 11:19:10 -04:00
|
|
|
[role="xpack"]
|
|
|
|
|
[[security-privileges]]
|
|
|
|
|
=== Security privileges
|
|
|
|
|
|
|
|
|
|
This section lists the privileges that you can assign to a role.
|
|
|
|
|
|
|
|
|
|
[[privileges-list-cluster]]
|
|
|
|
|
==== Cluster privileges
|
|
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
|
`all`::
|
|
|
|
|
All cluster administration operations, like snapshotting, node shutdown/restart,
|
|
|
|
|
settings update, rerouting, or managing users and roles.
|
|
|
|
|
|
|
|
|
|
`create_snapshot`::
|
|
|
|
|
Privileges to create snapshots for existing repositories. Can also list and view
|
|
|
|
|
details on existing repositories and snapshots.
|
|
|
|
|
|
|
|
|
|
`manage`::
|
|
|
|
|
Builds on `monitor` and adds cluster operations that change values in the cluster.
|
|
|
|
|
This includes snapshotting, updating settings, and rerouting. It also includes
|
|
|
|
|
obtaining snapshot and restore status. This privilege does not include the
|
|
|
|
|
ability to manage security.
|
|
|
|
|
|
|
|
|
|
`manage_api_key`::
|
|
|
|
|
All security-related operations on {es} API keys including
|
|
|
|
|
{ref}/security-api-create-api-key.html[creating new API keys],
|
|
|
|
|
{ref}/security-api-get-api-key.html[retrieving information about API keys], and
|
|
|
|
|
{ref}/security-api-invalidate-api-key.html[invalidating API keys].
|
|
|
|
|
+
|
|
|
|
|
--
|
|
|
|
|
[NOTE]
|
|
|
|
|
======
|
|
|
|
|
|
|
|
|
|
* When you create new API keys, they will always be owned by the authenticated
|
|
|
|
|
user.
|
|
|
|
|
* When you have this privilege, you can invalidate your own API keys and those
|
|
|
|
|
owned by other users.
|
|
|
|
|
|
|
|
|
|
======
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
`manage_ccr`::
|
|
|
|
|
All {ccr} operations related to managing follower indices and auto-follow
|
|
|
|
|
patterns. It also includes the authority to grant the privileges necessary to
|
|
|
|
|
manage follower indices and auto-follow patterns. This privilege is necessary
|
|
|
|
|
only on clusters that contain follower indices.
|
|
|
|
|
|
|
|
|
|
`manage_data_frame_transforms`::
|
|
|
|
|
All operations related to managing {transforms}.
|
|
|
|
|
|
|
|
|
|
`manage_ilm`::
|
|
|
|
|
All {Ilm} operations related to managing policies.
|
|
|
|
|
|
|
|
|
|
`manage_index_templates`::
|
|
|
|
|
All operations on index templates.
|
|
|
|
|
|
|
|
|
|
`manage_ingest_pipelines`::
|
|
|
|
|
All operations on ingest node pipelines.
|
|
|
|
|
|
|
|
|
|
`manage_ml`::
|
|
|
|
|
All {ml} operations, such as creating and deleting {dfeeds}, jobs, and model
|
|
|
|
|
snapshots.
|
|
|
|
|
+
|
|
|
|
|
--
|
|
|
|
|
NOTE: {dfeeds-cap} that were created prior to version 6.2 or created when
|
|
|
|
|
{security-features} were disabled run as a system user with elevated privileges,
|
|
|
|
|
including permission to read all indices. Newer {dfeeds} run with the security
|
|
|
|
|
roles of the user who created or updated them.
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
`manage_own_api_key`::
|
|
|
|
|
All security-related operations on {es} API keys that are owned by the current
|
|
|
|
|
authenticated user. The operations include
|
|
|
|
|
{ref}/security-api-create-api-key.html[creating new API keys],
|
|
|
|
|
{ref}/security-api-get-api-key.html[retrieving information about API keys], and
|
|
|
|
|
{ref}/security-api-invalidate-api-key.html[invalidating API keys].
|
|
|
|
|
|
|
|
|
|
`manage_pipeline`::
|
|
|
|
|
All operations on ingest pipelines.
|
|
|
|
|
|
|
|
|
|
`manage_rollup`::
|
|
|
|
|
All rollup operations, including creating, starting, stopping and deleting
|
|
|
|
|
rollup jobs.
|
|
|
|
|
|
|
|
|
|
`manage_saml`::
|
|
|
|
|
Enables the use of internal {es} APIs to initiate and manage SAML authentication
|
|
|
|
|
on behalf of other users.
|
|
|
|
|
|
|
|
|
|
`manage_security`::
|
|
|
|
|
All security-related operations such as CRUD operations on users and roles and
|
|
|
|
|
cache clearing.
|
|
|
|
|
|
|
|
|
|
`manage_token`::
|
|
|
|
|
All security-related operations on tokens that are generated by the {es} Token
|
|
|
|
|
Service.
|
|
|
|
|
|
|
|
|
|
`manage_watcher`::
|
|
|
|
|
All watcher operations, such as putting watches, executing, activate or acknowledging.
|
|
|
|
|
+
|
|
|
|
|
--
|
|
|
|
|
NOTE: Watches that were created prior to version 6.1 or created when the
|
|
|
|
|
{security-features} were disabled run as a system user with elevated privileges,
|
|
|
|
|
including permission to read and write all indices. Newer watches run with the
|
|
|
|
|
security roles of the user who created or updated them.
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
`monitor`::
|
|
|
|
|
All cluster read-only operations, like cluster health and state, hot threads,
|
|
|
|
|
node info, node and cluster stats, and pending cluster tasks.
|
|
|
|
|
|
|
|
|
|
`monitor_data_frame_transforms`::
|
|
|
|
|
All read-only operations related to {transforms}.
|
|
|
|
|
|
|
|
|
|
`monitor_ml`::
|
|
|
|
|
All read-only {ml} operations, such as getting information about {dfeeds}, jobs,
|
|
|
|
|
model snapshots, or results.
|
|
|
|
|
|
|
|
|
|
`monitor_rollup`::
|
|
|
|
|
All read-only rollup operations, such as viewing the list of historical and
|
|
|
|
|
currently running rollup jobs and their capabilities.
|
|
|
|
|
|
|
|
|
|
`monitor_watcher`::
|
|
|
|
|
All read-only watcher operations, such as getting a watch and watcher stats.
|
|
|
|
|
|
|
|
|
|
`read_ccr`::
|
|
|
|
|
All read-only {ccr} operations, such as getting information about indices and
|
|
|
|
|
metadata for leader indices in the cluster. It also includes the authority to
|
|
|
|
|
check whether users have the appropriate privileges to follow leader indices.
|
|
|
|
|
This privilege is necessary only on clusters that contain leader indices.
|
|
|
|
|
|
|
|
|
|
`read_ilm`::
|
|
|
|
|
All read-only {Ilm} operations, such as getting policies and checking the
|
|
|
|
|
status of {Ilm}
|
|
|
|
|
|
|
|
|
|
`transport_client`::
|
|
|
|
|
All privileges necessary for a transport client to connect. Required by the remote
|
|
|
|
|
cluster to enable <<cross-cluster-configuring,Cross Cluster Search>>.
|
|
|
|
|
|
|
|
|
|
[[privileges-list-indices]]
|
|
|
|
|
==== Indices privileges
|
|
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
|
`all`::
|
|
|
|
|
Any action on an index
|
|
|
|
|
|
|
|
|
|
`create`::
|
|
|
|
|
Privilege to index documents. Also grants access to the update mapping
|
|
|
|
|
action.
|
|
|
|
|
+
|
|
|
|
|
--
|
|
|
|
|
NOTE: This privilege does not restrict the index operation to the creation
|
2019-10-09 06:22:36 -04:00
|
|
|
of documents but instead restricts API use to the index API. The index API
|
|
|
|
|
allows a user to overwrite a previously indexed document. See the `create_doc`
|
|
|
|
|
privilege for an alternative.
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
`create_doc`::
|
|
|
|
|
Privilege to index documents. Also grants access to the update mapping action.
|
|
|
|
|
However, it does not enable a user to update existing documents.
|
|
|
|
|
+
|
|
|
|
|
--
|
|
|
|
|
NOTE: When indexing documents with an external `_id` either via the index API or
|
|
|
|
|
the bulk API, the request must use `op_type` as `create`. If `_id`s are
|
|
|
|
|
generated automatically, the authorization happens as if the `op_type` is set to
|
|
|
|
|
`create`.
|
2019-10-04 11:19:10 -04:00
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
`create_index`::
|
|
|
|
|
Privilege to create an index. A create index request may contain aliases to be
|
|
|
|
|
added to the index once created. In that case the request requires the `manage`
|
|
|
|
|
privilege as well, on both the index and the aliases names.
|
|
|
|
|
|
|
|
|
|
`delete`::
|
|
|
|
|
Privilege to delete documents.
|
|
|
|
|
|
|
|
|
|
`delete_index`::
|
|
|
|
|
Privilege to delete an index.
|
|
|
|
|
|
|
|
|
|
`index`::
|
|
|
|
|
Privilege to index and update documents. Also grants access to the update
|
|
|
|
|
mapping action.
|
|
|
|
|
|
|
|
|
|
`manage`::
|
|
|
|
|
All `monitor` privileges plus index administration (aliases, analyze, cache clear,
|
|
|
|
|
close, delete, exists, flush, mapping, open, force merge, refresh, settings,
|
|
|
|
|
search shards, templates, validate).
|
|
|
|
|
|
|
|
|
|
`manage_follow_index`::
|
|
|
|
|
All actions that are required to manage the lifecycle of a follower index, which
|
|
|
|
|
includes creating a follower index, closing it, and converting it to a regular
|
|
|
|
|
index. This privilege is necessary only on clusters that contain follower indices.
|
|
|
|
|
|
|
|
|
|
`manage_ilm`::
|
|
|
|
|
All {Ilm} operations relating to managing the execution of policies of an index
|
|
|
|
|
This includes operations like retrying policies, and removing a policy
|
|
|
|
|
from an index.
|
|
|
|
|
|
|
|
|
|
`manage_leader_index`::
|
|
|
|
|
All actions that are required to manage the lifecycle of a leader index, which
|
|
|
|
|
includes {ref}/ccr-post-forget-follower.html[forgetting a follower]. This
|
|
|
|
|
privilege is necessary only on clusters that contain leader indices.
|
|
|
|
|
|
|
|
|
|
`monitor`::
|
|
|
|
|
All actions that are required for monitoring (recovery, segments info, index
|
|
|
|
|
stats and status).
|
|
|
|
|
|
|
|
|
|
`read`::
|
|
|
|
|
Read-only access to actions (count, explain, get, mget, get indexed scripts,
|
|
|
|
|
more like this, multi percolate/search/termvector, percolate, scroll,
|
|
|
|
|
clear_scroll, search, suggest, tv).
|
|
|
|
|
|
|
|
|
|
`read_cross_cluster`::
|
|
|
|
|
Read-only access to the search action from a <<cross-cluster-configuring,remote cluster>>.
|
|
|
|
|
|
|
|
|
|
`view_index_metadata`::
|
|
|
|
|
Read-only access to index metadata (aliases, aliases exists, get index, exists, field mappings,
|
|
|
|
|
mappings, search shards, type exists, validate, warmers, settings, ilm). This
|
|
|
|
|
privilege is primarily available for use by {kib} users.
|
|
|
|
|
|
|
|
|
|
`write`::
|
|
|
|
|
Privilege to perform all write operations to documents, which includes the
|
|
|
|
|
permission to index, update, and delete documents as well as performing bulk
|
|
|
|
|
operations. Also grants access to the update mapping action.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
==== Run as privilege
|
|
|
|
|
|
|
|
|
|
The `run_as` permission enables an authenticated user to submit requests on
|
|
|
|
|
behalf of another user. The value can be a user name or a comma-separated list
|
|
|
|
|
of user names. (You can also specify users as an array of strings or a YAML
|
|
|
|
|
sequence.) For more information, see
|
|
|
|
|
<<run-as-privilege, Submitting Requests on Behalf of Other Users>>.
|
|
|
|
|
|
|
|
|
|
[[application-privileges]]
|
|
|
|
|
==== Application privileges
|
|
|
|
|
|
|
|
|
|
Application privileges are managed within {es} and can be retrieved with the
|
|
|
|
|
{ref}/security-api-has-privileges.html[has privileges API] and the
|
|
|
|
|
{ref}/security-api-get-privileges.html[get application privileges API]. They do
|
|
|
|
|
not, however, grant access to any actions or resources within {es}. Their
|
|
|
|
|
purpose is to enable applications to represent and store their own privilege
|
|
|
|
|
models within {es} roles.
|
|
|
|
|
|
|
|
|
|
To create application privileges, use the
|
|
|
|
|
{ref}/security-api-put-privileges.html[add application privileges API]. You can
|
|
|
|
|
then associate these application privileges with roles, as described in
|
|
|
|
|
<<defining-roles>>.
|
