diff --git a/docs/en/security/authentication.asciidoc b/docs/en/security/authentication.asciidoc index fe57821afe4..56a794f2167 100644 --- a/docs/en/security/authentication.asciidoc +++ b/docs/en/security/authentication.asciidoc @@ -22,7 +22,7 @@ Please read <> and .{security} Built-in Users |======== | Name | Description -| `elastic` | A built-in <>. +| `elastic` | A built-in _superuser_. See <>. | `kibana` | The user Kibana uses to connect and communicate with Elasticsearch. | `logstash_system` | The user Logstash uses when storing monitoring information in Elasticsearch. |======== @@ -39,7 +39,7 @@ You can update passwords from the *Management > Users* UI in Kibana or with the [source,js] --------------------------------------------------------------------- -PUT _xpack/security/user/elastic/_password +PUT _xpack/security/user/elastic/_password { "password": "elasticpassword" } @@ -48,7 +48,7 @@ PUT _xpack/security/user/elastic/_password [source,js] --------------------------------------------------------------------- -PUT _xpack/security/user/kibana/_password +PUT _xpack/security/user/kibana/_password { "password": "kibanapassword" } @@ -168,8 +168,8 @@ NOTE: Some systems (e.g. Active Directory) have a temporary lock-out period afte The default realm chain contains the `native` and `file` realms. To explicitly, configure a realm chain, you specify the chain in `elasticsearch.yml`. When you -configure a realm chain, only the realms you specify are used for authentication. -To use the `native` and `file` realms, you must include them in the chain. +configure a realm chain, only the realms you specify are used for authentication. +To use the `native` and `file` realms, you must include them in the chain. The following snippet configures a realm chain that includes the `file` and `native` realms, as well as two LDAP realms and an Active Directory realm. diff --git a/docs/en/security/authorization.asciidoc b/docs/en/security/authorization.asciidoc index fcae506f8ec..165bbfa55c1 100644 --- a/docs/en/security/authorization.asciidoc +++ b/docs/en/security/authorization.asciidoc @@ -51,53 +51,14 @@ ways depending on the realms by which the users are authenticated. [[built-in-roles]] === Built-in Roles -{security} applies a default role to all users, including <>. The default role enables users to access the authenticate -endpoint, change their own passwords, and get information about themselves. +{security} applies a default role to all users, including +<>. The default role enables users to access +the authenticate endpoint, change their own passwords, and get information about +themselves. {security} also provides a set of built-in roles you can explicitly assign to users. These roles have a fixed set of privileges and cannot be updated. -[[built-in-roles-superuser]] -`superuser`:: -Grants full access to the cluster, including all indices and data. A user with -the `superuser` role can also manage users and roles and <> any other user in the system. Due to the permissive nature of -this role, take extra care when assigning it to a user. - -[[built-in-roles-transport-client]] -`transport_client`:: -Grants the privileges required to access the cluster through the Java Transport Client. The Java Transport Client fetches information about the nodes in the -cluster using the _Node Liveness API_ and the _Cluster State API_ (when -sniffing is enabled). Assign your users this role if they use the -Transport Client. -+ -NOTE: Using the Transport Client effectively means the users are granted access -to the cluster state. This means users can view the metadata over all indices, -index templates, mappings, node and basically everything about the cluster. -However, this role does not grant permission to view the data in all indices. - -[[built-in-roles-kibana-user]] -`kibana_user` :: -Grants the minimum privileges required for any user of Kibana. This role grants -access to the Kibana indices and grants monitoring privileges for the cluster. - -[[built-in-roles-monitoring-user]] -`monitoring_user` :: -Grants the minimum privileges required for any user of Monitoring other than those -required to use Kibana. This role grants access to the monitoring indices. Monitoring -users should also be assigned the `kibana_user` role. - -[[built-in-roles-reporting-user]] -`reporting_user` :: -Grants the specific privileges required for users of Reporting other than those -required to use Kibana. This role grants access to the reporting indices. Reporting -users should also be assigned the `kibana_user` role and a role that grants them -access to the data that will be used to generate reports with. - -[[built-in-roles-remote-monitoring-agent]] -`remote_monitoring_agent` :: -Grants the minimum privileges required for a remote monitoring agent to write data -into this cluster. - [[built-in-roles-ingest-user]] `ingest_admin` :: Grants access to manage *all* index templates and *all* ingest pipeline configurations. @@ -107,12 +68,17 @@ must be defined in a separate role. [[built-in-roles-kibana-system]] `kibana_system` :: -Grants access necessary for the Kibana system user to read from and write to the Kibana indices -and check the availability of the Elasticsearch cluster. +Grants access necessary for the Kibana system user to read from and write to the +Kibana indices and check the availability of the Elasticsearch cluster. + NOTE: This role should not be assigned to users as the granted permissions may change between releases. +[[built-in-roles-kibana-user]] +`kibana_user`:: +Grants the minimum privileges required for any user of Kibana. This role grants +access to the Kibana indices and grants monitoring privileges for the cluster. + [[built-in-roles-logstash-system]] `logstash_system` :: Grants access necessary for the Logstash system user to send data to Elasticsearch. @@ -120,18 +86,6 @@ Grants access necessary for the Logstash system user to send data to Elasticsear NOTE: This role should not be assigned to users as the granted permissions may change between releases. -[[built-in-roles-watcher-user]] -`watcher_user`:: -+ -Grants read access to the `.watches` index, the get watch action and the watcher -stats. - -[[built-in-roles-watcher-admin]] -`watcher_admin`:: -+ -Grants write access to the `.watches` index, read access to the watch history and -the triggered watches index and allows to execute all watcher actions. - [[built-in-roles-ml-admin]] `machine_learning_admin`:: Grants `manage_ml` cluster privileges and read access to the `.ml-*` indices. @@ -143,6 +97,57 @@ status, and results. This role grants `monitor_ml` cluster privileges and read access to the `.ml-notifications` and `.ml-anomalies*` indices, which store {ml} results. +[[built-in-roles-monitoring-user]] +`monitoring_user`:: +Grants the minimum privileges required for any user of Monitoring other than those +required to use Kibana. This role grants access to the monitoring indices. +Monitoring users should also be assigned the `kibana_user` role. + +[[built-in-roles-remote-monitoring-agent]] +`remote_monitoring_agent`:: +Grants the minimum privileges required for a remote monitoring agent to write data +into this cluster. + +[[built-in-roles-reporting-user]] +`reporting_user`:: +Grants the specific privileges required for users of Reporting other than those +required to use Kibana. This role grants access to the reporting indices. Reporting +users should also be assigned the `kibana_user` role and a role that grants them +access to the data that will be used to generate reports with. + +[[built-in-roles-superuser]] +`superuser`:: +Grants full access to the cluster, including all indices and data. A user with +the `superuser` role can also manage users and roles and +<> any other user in the system. Due to the +permissive nature of this role, take extra care when assigning it to a user. + +[[built-in-roles-transport-client]] +`transport_client`:: +Grants the privileges required to access the cluster through the Java Transport +Client. The Java Transport Client fetches information about the nodes in the +cluster using the _Node Liveness API_ and the _Cluster State API_ (when +sniffing is enabled). Assign your users this role if they use the +Transport Client. ++ +NOTE: Using the Transport Client effectively means the users are granted access +to the cluster state. This means users can view the metadata over all indices, +index templates, mappings, node and basically everything about the cluster. +However, this role does not grant permission to view the data in all indices. + +[[built-in-roles-watcher-admin]] +`watcher_admin`:: ++ +Grants write access to the `.watches` index, read access to the watch history and +the triggered watches index and allows to execute all watcher actions. + +[[built-in-roles-watcher-user]] +`watcher_user`:: ++ +Grants read access to the `.watches` index, the get watch action and the watcher +stats. + + [[defining-roles]] === Defining Roles