[DOCS] Clarify built-in and internal uses/roles (elastic/x-pack-elasticsearch#1269)

- Describe internal users (_system, _xpack)
- Explain that built-in users are not the same as native users
- More clarification around logstash_system role and kibana_system role.

Closes: elastic/x-pack-elasticsearch#734
Closes: elastic/x-pack-elasticsearch#268
Closes: elastic/x-pack-elasticsearch#1116

Original commit: elastic/x-pack-elasticsearch@2ecbd3419f

docs/en/security/authentication.asciidoc

@@ -27,6 +27,21 @@ Please read <<reset-built-in-user-passwords,Reset Built-in User Passwords>> and
 | `logstash_system`  | The user Logstash uses when storing monitoring information in Elasticsearch.
 |========
 
+[float]
+[[built-in-user-explanation]]
+==== How the Built-in Users Work
+These built-in users are stored within a special `.security` index managed by
+{security}.
+This means that, if the password is changed, or a user is disabled, then that
+change is automatically reflected on each node in the cluster. It also means
+that if your `.security` index is deleted, or restored from a snapshot, then
+any changes you have applied will be lost.
+
+Although they share the same API, the built-in users are separate and distinct
+from users managed by the <<native-realm, native realm>>. Disabling the native
+realm will not have any effect on the built-in users. The built-in users can
+be disabled individually, using the <<security-api-users, user management api>>.
+
 [float]
 [[reset-built-in-user-passwords]]
 ==== Reset Built-in User Passwords
@@ -112,6 +127,20 @@ mode until you make this configuration change.
 
 =============================================================================
 
+[float]
+[[internal-users]]
+=== Internal Users
+
+{security} has two _internal_ users (`_system` and `_xpack`) that are
+responsible for the operations that take place inside an Elasticsearch cluster.
+
+These users are only used by requests that originate from within the cluster.
+For this reason, they cannot be used to authenticate against the API, and there
+is no password to manage or reset.
+
+From time-to-time you may find a reference to one of these users inside your
+logs, including <<auditing, audit logs>>.
+
 === How Authentication Works
 
 Authentication in {security} is handled by one or more authentication services

docs/en/security/authorization.asciidoc

@@ -68,8 +68,9 @@ 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
+Grants access necessary for the <<kibana, Kibana system user>>
-Kibana indices and check the availability of the Elasticsearch cluster.
+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.
@@ -81,10 +82,14 @@ 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.
+Grants access necessary for the <<ls-monitoring-user, Logstash system user>>
+to send system-level data (such as monitoring) to Elasticsearch.
 +
 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-ml-admin]]
 `machine_learning_admin`::