[DOCS] Removes redundant authorization pages

x-pack/docs/en/security/authorization/built-in-roles.asciidoc

@@ -1,114 +0,0 @@
-[role="xpack"]
-[[built-in-roles]]
-=== Built-in roles
-
-{security} applies a default role to all users, including
-<<anonymous-access, anonymous users>>. 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-ingest-user]] `ingest_admin` ::
-Grants access to manage *all* index templates and *all* ingest pipeline configurations.
-+
-NOTE: This role does *not* provide the ability to create indices; those privileges
-must be defined in a separate role.
-
-[[built-in-roles-kibana-dashboard]] `kibana_dashboard_only_user` ::
-Grants access to the {kib} Dashboard and read-only permissions on the `.kibana`
-index. This role does not have access to editing tools in {kib}. For more
-information, see
-{kibana-ref}/xpack-dashboard-only-mode.html[{kib} Dashboard Only Mode].
-
-[[built-in-roles-kibana-system]] `kibana_system` ::
-Grants access necessary for the {kib} system user to read from and write to the
-{kib} indices, manage index templates, and check the availability of the {es} cluster.
-This role grants read access to the `.monitoring-*` indices and read and write access
-to the `.reporting-*` indices. For more information, see
-{kibana-ref}/using-kibana-with-security.html[Configuring Security in {kib}].
-+
-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 {kib}. This role grants
-access to the {kib} indices and grants  monitoring privileges for the cluster.
-
-[[built-in-roles-logstash-admin]] `logstash_admin` ::
-Grants access to the `.logstash*` indices for managing configurations.
-
-[[built-in-roles-logstash-system]] `logstash_system` ::
-Grants access necessary for the Logstash system user to send system-level data
-(such as monitoring) to {es}. For more information, see
-{logstash-ref}/ls-security.html[Configuring Security in Logstash].
-+
-NOTE: This role should not be assigned to users as the granted permissions may
-change between releases.
-+
-NOTE: This role does not provide access to the logstash indices and is not
-suitable for use within a Logstash pipeline.
-
-[[built-in-roles-beats-system]] `beats_system` ::
-Grants access necessary for the Beats system user to send system-level data
-(such as monitoring) to {es}.
-+
-NOTE: This role should not be assigned to users as the granted permissions may
-change between releases.
-+
-NOTE: This role does not provide access to the beats indices and is not
-suitable for writing beats output to {es}.
-
-[[built-in-roles-ml-admin]] `machine_learning_admin`::
-Grants `manage_ml` cluster privileges and read access to the `.ml-*` indices.
-
-[[built-in-roles-ml-user]] `machine_learning_user`::
-Grants the minimum privileges required to view {xpackml} configuration,
-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 {kib}. This role grants access to the monitoring indices and grants
-privileges necessary for reading basic cluster information. 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 {kib}. 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
-<<run-as-privilege, impersonate>> 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.

x-pack/docs/en/security/authorization/overview.asciidoc

@@ -1,74 +0,0 @@
-[role="xpack"]
-[[authorization]]
-== Configuring role-based access control
-
-{security} introduces the concept of _authorization_ to {es}.
-Authorization is the process of determining whether the user behind an incoming
-request is allowed to execute it. This process takes place once a request is
-successfully authenticated and the user behind the request is identified.
-
-[[roles]]
-[float]
-=== Roles, permissions, and privileges
-
-The authorization process revolves around the following 5 constructs:
-
-_Secured Resource_::
-A resource to which access is restricted. Indices/aliases, documents, fields,
-users and the {es} cluster itself are all examples of secured objects.
-
-_Privilege_::
-A named group representing one or more actions that a user may execute against a
-secured resource. Each secured resource has its own sets of available privileges.
-For example, `read` is an index privilege that represents all actions that enable
-reading the indexed/stored data. For a complete list of available privileges
-see <<security-privileges>>.
-
-_Permissions_::
-A set of one or more privileges against a secured resource. Permissions can
-easily be described in words, here are few examples:
- * `read` privilege on the `products` index
- * `manage` privilege on the cluster
- * `run_as` privilege on `john` user
- * `read` privilege on documents that match query X
- * `read` privilege on `credit_card` field
-
-_Role_::
-A named sets of permissions
-
-_User_::
-The authenticated user.
-
-A secure {es} cluster manages the privileges of users through _roles_.
-A role has a unique name and identifies a set of permissions that translate to
-privileges on resources. A user can be associated with an arbitrary number of
-roles. The total set of permissions that a user has is therefore defined by
-union of the permissions in all its roles.
-
-As an administrator, you will need to define the roles that you want to use,
-then assign users to the roles. These can be assigned to users in a number of
-ways depending on the realms by which the users are authenticated.
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/built-in-roles.asciidoc
-include::built-in-roles.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/managing-roles.asciidoc
-include::managing-roles.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/privileges.asciidoc
-include::privileges.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/alias-privileges.asciidoc
-include::alias-privileges.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/mapping-roles.asciidoc
-include::mapping-roles.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/field-and-document-access-control.asciidoc
-include::field-and-document-access-control.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/run-as-privilege.asciidoc
-include::run-as-privilege.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/custom-roles-provider.asciidoc
-include::custom-roles-provider.asciidoc[]

x-pack/docs/en/security/authorization/privileges.asciidoc

@@ -1,135 +0,0 @@
-[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.
-
-`monitor`::
-All cluster read-only operations, like cluster health and state, hot threads, 
-node info, node and cluster stats, and pending cluster tasks.
-
-`monitor_ml`::
-All read only {ml} operations, such as getting information about {dfeeds}, jobs,
-model snapshots, or results.
-
-`monitor_watcher`::
-All read only watcher operations, such as getting a watch and watcher stats.
-
-`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_index_templates`::
-All operations on index templates.
-
-`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}
-was 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_pipeline`::
-All operations on ingest pipelines.
-
-`manage_security`::
-All security related operations such as CRUD operations on users and roles and
-cache clearing.
-
-`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 {security}
-was 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.
-
---
-
-`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
-
-`monitor`::
-All actions that are required for monitoring (recovery, segments info, index 
-stats and status).
-
-`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).
-
-`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). This
-privilege is primarily available for use by {kib} users.
-
-`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>>.
-
-`index`::
-Privilege to index and update documents. Also grants access to the update
-mapping action.
-
-`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
-of documents but instead restricts API use to the index API. The index API allows a user
-to overwrite a previously indexed document.
-
---
-
-`delete`::
-Privilege to delete documents.
-
-`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.
-
-`delete_index`::
-Privilege to delete an index.
-
-`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.
-
-==== 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>>.