diff --git a/libbeat/docs/monitoring/monitoring-beats.asciidoc b/libbeat/docs/monitoring/monitoring-beats.asciidoc
index 112adcb1e1ac..d40b01718564 100644
--- a/libbeat/docs/monitoring/monitoring-beats.asciidoc
+++ b/libbeat/docs/monitoring/monitoring-beats.asciidoc
@@ -37,9 +37,13 @@ information, see
 configured {es} output, specify the following minimal configuration:
 +
 --
-[source, yml]
+["source","yml",subs="attributes"]
 --------------------
-xpack.monitoring.enabled: true
+xpack.monitoring:
+  enabled: true
+  elasticsearch:
+    username: {beat_monitoring_user}
+    password: somepassword
 --------------------
 
 If you configured a different output, such as {ls}, you must specify additional
diff --git a/libbeat/docs/security/basic-auth.asciidoc b/libbeat/docs/security/basic-auth.asciidoc
index 986b277d6304..fa7ac9de12ca 100644
--- a/libbeat/docs/security/basic-auth.asciidoc
+++ b/libbeat/docs/security/basic-auth.asciidoc
@@ -6,168 +6,55 @@ When sending data to a secured cluster through the `elasticsearch`
 output, {beatname_uc} must either provide basic authentication credentials
 or present a client certificate.
 
-To configure authentication credentials for {beatname_uc}:
+*Before you begin:* <<feature-roles>>.
 
-. Create a writer role that has the following privileges:
-+
---
-ifeval::["{beatname_lc}"!="filebeat"]
-* *Cluster*: `manage_index_templates` and `monitor`
-endif::[]
-ifeval::["{beatname_lc}"=="filebeat"]
-* *Cluster*: `manage_index_templates`, `monitor`, and
-`manage_ingest_pipelines`
-endif::[]
-* *Index*: `write` and `create_index` on the {beatname_uc} indices 
---
-+
-You can create roles from the **Management / Roles** UI in {kib} or through the
-`role` API. For example, the following request creates a role named
-++{beat_default_index_prefix}_writer++:
-+
---
-ifeval::["{beatname_lc}"!="filebeat"]
-["source","sh",subs="attributes,callouts"]
----------------------------------------------------------------
-POST _security/role/{beat_default_index_prefix}_writer
-{
-  "cluster": ["manage_index_templates","monitor"],
-  "indices": [
-    {
-      "names": [ "{beat_default_index_prefix}-*" ], <1>
-      "privileges": ["write","create_index"]
-    }
-  ]
-}
----------------------------------------------------------------
-// CONSOLE
-<1> If you use a custom {beatname_uc} index pattern, specify that pattern
-instead of the default ++{beat_default_index_prefix}-*++ pattern.
-endif::[]
-ifeval::["{beatname_lc}"=="filebeat"]
-["source","sh",subs="attributes,callouts"]
----------------------------------------------------------------
-POST _security/role/{beat_default_index_prefix}_writer
-{
-  "cluster": ["manage_index_templates","monitor","manage_ingest_pipelines"], <1>
-  "indices": [
-    {
-      "names": [ "{beat_default_index_prefix}-*" ], <2>
-      "privileges": ["write","create_index"]
-    }
-  ]
-}
----------------------------------------------------------------
-// CONSOLE
-<1> The `manage_ingest_pipelines` cluster privilege is required to run
-{beatname_uc} modules.
-<2> If you use a custom {beatname_uc} index pattern, specify that pattern
-instead of the default ++{beat_default_index_prefix}-*++ pattern.
-endif::[]
---
-
-ifndef::no_ilm[]
-. If you plan to use {ref}/getting-started-index-lifecycle-management.html[index
-lifecycle management], create a role that has the following privileges. These
-privileges are required to load index lifecycle policies and create and manage
-rollover indices:
-+
-* *Cluster:* `manage_ilm`
-* *Index:* `write`, `create_index`, `manage`, and `manage_ilm` on the 
-{beatname_uc} indices
-+
---
-["source","sh",subs="attributes"]
----------------------------------------------------------------
-POST _xpack/security/role/{beat_default_index_prefix}_ilm
-{
-  "cluster": ["manage_ilm"],
-  "indices": [
-    {
-      "names": [ "{beat_default_index_prefix}-*","shrink-{beat_default_index_prefix}-*"],
-      "privileges": ["write","create_index","manage","manage_ilm"]
-    }
-  ]
-}
----------------------------------------------------------------
-// CONSOLE
---
-endif::no_ilm[]
-
-. Assign the writer role to the user that {beatname_uc} will use to connect to
-{es}. Make sure you also assign any roles that are required for specific
-features. For the list of features and required roles, see <<feature-roles>>.
-
-.. To authenticate as a native user, create a user for {beatname_uc} to use
-internally and assign it the writer role, plus any other roles that are
-needed.
-+
-You can create users from the **Management / Users** UI in {kib} or through the
-`user` API. For example, following request creates a user
-named ++{beat_default_index_prefix}_internal++ that has the
-++{beat_default_index_prefix}_writer++ and `kibana_user` roles:
-+
---
-["source","sh",subs="attributes,callouts"]
----------------------------------------------------------------
-POST /_security/user/{beat_default_index_prefix}_internal
-{
-  "password" : "{pwd}",
-  "roles" : [ "{beat_default_index_prefix}_writer","kibana_user"],
-  "full_name" : "Internal {beatname_uc} User"
-}
----------------------------------------------------------------
-// CONSOLE
+You specify authentication credentials in the {beatname_uc} configuration
+file: 
 
---
-
-.. To use PKI authentication, assign the writer role, plus any other roles that are
-needed, in the `role_mapping.yml` configuration file. Specify the user by the
-distinguished name that appears in its certificate:
+* To use basic authentication, specify the `username` and `password` settings
+under `output.elasticsearch`. For example: 
 +
 --
 ["source","yaml",subs="attributes,callouts"]
----------------------------------------------------------------
-{beat_default_index_prefix}_writer:
-  - "cn=Internal {beatname_uc} User,ou=example,o=com"
-kibana_user:
-  - "cn=Internal {beatname_uc} User,ou=example,o=com"
----------------------------------------------------------------
-
-
-For more information, see
-{xpack-ref}/mapping-roles.html#mapping-roles-file[Using Role Mapping Files].
---
-
-. In the {beatname_uc} configuration file, specify authentication credentials
-for the `elasticsearch` output:
-
-
-.. To use basic authentication, configure the `username` and `password` settings.
-For example, the following {beatname_uc} output configuration uses the native
-++{beat_default_index_prefix}_internal++ user to connect to {es}: 
-+
-["source","js",subs="attributes,callouts"]
---------------------------------------------------
+----
 output.elasticsearch:
   hosts: ["localhost:9200"]
   username: "{beat_default_index_prefix}_internal" <1>
   password: "{pwd}" <2>
---------------------------------------------------
-<1> You created this user earlier.
+----
+<1> Let's assume this user has the privileges required to publish events to
+{es}.
 <2> The example shows a hard-coded password, but you should store sensitive
 values in the <<keystore,secrets keystore>>.
+--
++
+If you've configured the {kib} endpoint, also specify credentials for
+authenticating with {kib}. For example:
++
+["source","yaml",subs="attributes,callouts"]
+----
+setup.kibana:
+  host: "mykibanahost:5601"
+  username: "{beat_default_index_prefix}_internal" <1>
+  password: "{pwd}" 
+----
+<1> Let's assume this user has the privileges required to set up dashboards.
 
-.. To use PKI authentication, configure the `certificate` and `key` settings:
+* To use Public Key Infrastructure (PKI) certificates to authenticate users,
+configure the `certificate` and `key` settings. These settings assume that the
+distinguished name (DN) in the certificate is mapped to the appropriate roles in
+the `role_mapping.yml` file on each node in the {es} cluster. For more
+information, see {xpack-ref}/mapping-roles.html#mapping-roles-file[Using Role
+Mapping Files].
 +
-["source","js",subs="attributes,callouts"]
+["source","yaml",subs="attributes,callouts"]
 --------------------------------------------------
 output.elasticsearch:
   hosts: ["localhost:9200"]
-  ssl.certificate: "/etc/pki/client/cert.pem" <1>
+  ssl.certificate: "/etc/pki/client/cert.pem"
   ssl.key: "/etc/pki/client/cert.key"
 --------------------------------------------------
-<1> The distinguished name (DN) in the certificate must be mapped to
-the ++{beat_default_index_prefix}_writer++ and `kibana_user` roles in the
-`role_mapping.yml` configuration file on each node in the {es} cluster.
 
+To learn more about {stack} security features and other types of
+authentication, see {stack-ov}/elasticsearch-security.html[Securing the
+{stack}].
diff --git a/libbeat/docs/security/securing-beats.asciidoc b/libbeat/docs/security/securing-beats.asciidoc
index 96c143397d4e..c06fde066c82 100644
--- a/libbeat/docs/security/securing-beats.asciidoc
+++ b/libbeat/docs/security/securing-beats.asciidoc
@@ -10,25 +10,15 @@ If you want {beatname_uc} to connect to a cluster that has
 {stack-ov}/elasticsearch-security.html[{security}] enabled, there are extra
 configuration steps:
 
-. <<beats-basic-auth>>.
+. <<feature-roles>>.
 +
-ifeval::["{beatname_lc}"=="filebeat"]
-To send data to a secured cluster through the `elasticsearch` output,
-{beatname_uc} needs to authenticate as a user who can manage index templates,
-monitor the cluster, create indices, read and write to the indices
-it creates, and manage ingest pipelines. 
-endif::[]
-ifeval::["{beatname_lc}"!="filebeat"]
-To send data to a secured cluster through the `elasticsearch` output,
-{beatname_uc} needs to authenticate as a user who can manage index templates,
-monitor the cluster, create indices, and read and write to the indices
-it creates. 
-endif::[]
+You can use role-based access control to grant {beatname_uc} users access to
+secured resources. 
 
-. <<beats-user-access>>.
+. <<beats-basic-auth>>.
 +
-To search the indexed {beatname_uc} data and visualize it in {kib}, users need
-access to the indices {beatname_uc} creates.
+To interact with a secured cluster, {beatname_uc} must either provide basic
+authentication credentials or present a client certificate.
 
 . <<beats-tls>>.
 +
@@ -44,48 +34,10 @@ password, set it up now.
 For more information about {security}, see
 {xpack-ref}/elasticsearch-security.html[Securing the {stack}].
 
-[[feature-roles]]
-=== {beatname_uc} features that require authorization
-
-After securing {beatname_uc}, make sure your users have the roles (or associated
-privileges) required to use these {beatname_uc} features. Note that some of the
-roles shown here are {xpack-ref}/built-in-roles.html[built-in], and some
-are user-defined.
-
-[options="header"]
-|=======
-|Feature | Role
-|Send data to a secured cluster   | ++{beat_default_index_prefix}_writer++ footnoteref:[noteA,These roles are user-defined.]
-ifeval::["{beatname_lc}"=="filebeat"]
-|Run Filebeat modules | ++{beat_default_index_prefix}_writer++ footnoteref:[noteA]
-endif::[]
-|Load index templates | ++{beat_default_index_prefix}_writer++ footnoteref:[noteA] and `kibana_user`
-ifndef::no_dashboards[]
-|Load {beatname_uc} dashboards into {kib} | ++{beat_default_index_prefix}_writer++ footnoteref:[noteA] and `kibana_user`
-endif::[]
-ifdef::has_ml_jobs[]
-|Load machine learning jobs | `machine_learning_admin`
-endif::[]
-|Read indices created by {beatname_uc} | ++{beat_default_index_prefix}_reader++ footnoteref:[noteA] 
-ifndef::no_dashboards[]
-|View {beatname_uc} dashboards in {kib} | `kibana_user`
-endif::[]
-ifdef::has_central_config[]
-|Store and manage configurations in a central location in {kib} | `beats_admin`
-endif::[]
-ifndef::no_ilm[]
-|Load index lifecycle policies and use index lifecycle management | +{beatname_lc}_ilm+ footnoteref:[noteA]
-endif::[]
-|=======
-
-To create the user-defined roles shown here, see <<beats-basic-auth>> and
-<<beats-user-access>>. You may want to define additional roles to provide more
-restrictive access.
+include::users.asciidoc[]
 
 include::basic-auth.asciidoc[]
 
-include::user-access.asciidoc[]
-
 include::tls.asciidoc[]
 
 include::beats-system.asciidoc[]
diff --git a/libbeat/docs/security/user-access.asciidoc b/libbeat/docs/security/user-access.asciidoc
deleted file mode 100644
index 4828f7f2012a..000000000000
--- a/libbeat/docs/security/user-access.asciidoc
+++ /dev/null
@@ -1,71 +0,0 @@
-[role="xpack"]
-[[beats-user-access]]
-=== Grant users access to {beatname_uc} indices
-
-To enable users to access the indices {beatname_uc} creates, grant them `read`
-and `view_index_metadata` privileges on the {beatname_uc} indices. If they're
-using {kib}, they also need the `kibana_user` role.
-
-. Create a reader role that has the `read` and `view_index_metadata` privileges
-on the {beatname_uc} indices.
-+
-You can create roles from the **Management > Roles** UI in {kib} or through the
-`role` API. For example, the following request creates a role named
-++{beat_default_index_prefix}_reader++:
-+
---
-["source","sh",subs="attributes,callouts"]
----------------------------------------------------------------
-POST _security/role/{beat_default_index_prefix}_reader
-{
-  "indices": [
-    {
-      "names": [ "{beat_default_index_prefix}-*" ], <1>
-      "privileges": ["read","view_index_metadata"]
-    }
-  ]
-}
----------------------------------------------------------------
-// CONSOLE
-<1> If you use a custom {beatname_uc} index pattern, specify that pattern
-instead of the default ++{beat_default_index_prefix}-*++ pattern.
---
-
-. Assign your users the reader role so they can access the {beatname_uc}
-indices. For {kib} users who need to visualize the data, also assign the
-`kibana_user` role:
-
-.. If you're using the `native` realm, you can assign roles with the
-**Management > Users** UI in {kib} or through the `user` API. For example, the
-following request grants ++{beat_default_index_prefix}_user++ the
-++{beat_default_index_prefix}_reader++ and `kibana_user` roles:
-+
---
-["source", "sh", subs="attributes,callouts"]
----------------------------------------------------------------
-POST /_security/user/{beat_default_index_prefix}_user
-{
-  "password" : "{pwd}",
-  "roles" : [ "{beat_default_index_prefix}_reader","kibana_user"],
-  "full_name" : "{beatname_uc} User"
-}
----------------------------------------------------------------
-// CONSOLE
---
-.. If you're using the LDAP, Active Directory, or PKI realms, you assign the
-roles in the `role_mapping.yml` configuration file. For example, the following
-snippet grants ++{beatname_uc} User++ the ++{beat_default_index_prefix}_reader++
-and `kibana_user` roles:
-+
---
-["source", "yaml", subs="attributes,callouts"]
----------------------------------------------------------------
-{beat_default_index_prefix}_reader:
-  - "cn={beatname_uc} User,dc=example,dc=com"
-kibana_user:
-  - "cn={beatname_uc} User,dc=example,dc=com"
----------------------------------------------------------------
-
-For more information, see
-{xpack-ref}/mapping-roles.html#mapping-roles-file[Using Role Mapping Files].
---
diff --git a/libbeat/docs/security/users.asciidoc b/libbeat/docs/security/users.asciidoc
new file mode 100644
index 000000000000..a0797f261b55
--- /dev/null
+++ b/libbeat/docs/security/users.asciidoc
@@ -0,0 +1,181 @@
+[role="xpack"]
+[[feature-roles]]
+=== Grant users access to secured resources
+
+
+You can use role-based access control to grant users access to secured
+resources. The roles that you set up depend on your organization's security
+requirements and the minimum privileges required to use specific features. 
+
+{beatname_uc} users typically perform these main roles: they do the initial
+setup, publish monitoring information, and publish events. If they're using
+{kib}, they view and sometimes create visualizations that access {beatname_uc}
+indices.
+
+{security} provides pre-built roles that grant _some_ of the privileges needed
+by {beatname_uc} users. When possible, use the built-in roles to minimize the
+affect of future changes on your security strategy.
+
+For privileges not granted by existing roles, create new roles. At a minimum,
+create a role for setting up {beatname_uc}, a role for publishing events, and a
+role for reading {beatname_uc} indices. Assign these new roles, along with the
+pre-built roles, to grant the full set of privileges required by {beatname_uc}
+users.
+
+The following sections describe the privileges and roles required to perform
+specific job roles. 
+
+[[privileges-to-setup-beats]]
+==== Privileges needed for initial setup
+
+Users who set up {beatname_uc} typically need to load mappings, dashboards, and
+other objects used to index data into {es} and visualize it in {kib}. The
+privileges required depend on the setup tasks users need to perform.
+
+NOTE: These instructions assume that you are using the default name for
+{beatname_uc} indices. If you are using a custom name, modify the privileges to
+match your index naming pattern.
+
+[options="header"]
+|====
+|Task | Required privileges and roles
+
+.3+|Set up index templates
+|`manage_index_templates` and `monitor` on cluster
+|`manage_ilm` on cluster (if cluster supports index lifecycle management)
+|`manage` on +{beat_default_index_prefix}-*+ indices (if cluster supports index lifecycle management)
+
+ifndef::no_dashboards[]
+|Set up example dashboards
+|`kibana_user` role
+endif::no_dashboards[]
+
+ifdef::has_ml_jobs[]
+.3+|Set up machine learning job configurations 
+|`manage_ml` and `monitor` on cluster
+|`read` on +{beat_default_index_prefix}-*+ indices
+|`kibana_user` role
+endif::has_ml_jobs[]
+
+ifeval::["{beatname_lc}"=="filebeat"]
+.2+|Set up ingest pipelines
+|`monitor` on cluster
+|`ingest_admin` role
+endif::[]
+
+.2+|Set up index lifecycle policies
+|`manage_ilm`, `manage_index_templates`, and `monitor` on cluster
+|`manage` on +{beat_default_index_prefix}-*+ indices
+
+ifdef::has_central_config[]
+|Enroll and manage configurations in Beats central management
+|`beats_admin` and `kibana_user` roles
+endif::has_central_config[]
+|====
+
+[[privileges-to-publish-monitoring]]
+==== Privileges needed to publish and view monitoring information
+
+{security} provides the +{beat_default_index_prefix}_system+
+{stack-ov}/built-in-users.html[built-in user] and
++{beat_default_index_prefix}_system+ {stack-ov}/built-in-roles.html[built-in
+role] for sending monitoring information. You can use the built-in user, or
+create a user who has the privileges needed to send monitoring information.
+If you use the +{beat_default_index_prefix}_system+ user, make sure you
+<<beats-system-user,set the password>>.
+
+[options="header"]
+|====
+|Task | Required privileges and roles
+
+|Send monitoring info
+|`monitor` on cluster
+
+|Use *Stack Monitoring* in {kib} to monitor {beatname_uc}
+|`monitoring_user` and `kibana_user` roles
+|====
+
+
+[[privileges-to-publish-events]]
+==== Privileges needed to publish events
+
+Users who publish events to {es} need to create and read from {beatname_uc}
+indices. The privileges required for this role depend on the tasks users
+need to perform:
+
+[options="header"]
+|====
+|Task | Required privileges and roles
+
+.3+|Send data to a secured cluster without index lifecycle management
+|`monitor` on cluster
+ifeval::["{beatname_lc}"=="filebeat"]
+(and `manage_pipeline` if {beatname_uc} modules are used)
+endif::[]
+|`create_index` and `index` on +{beat_default_index_prefix}-*+ indices
+|also requires privileges to <<privileges-to-setup-beats,set up index templates>>
+unless you've disabled automatic template loading
+
+.2+|Send data to a secured cluster that supports index lifecycle management
+|`manage_index_templates`,`manage_ilm` footnote:[Use `read_ilm` instead of
+`manage_ilm` if you pre-loaded the lifecycle policy], and `monitor`
+on cluster
+ifeval::["{beatname_lc}"=="filebeat"]
+(and `manage_pipeline` if {beatname_uc} modules are used)
+endif::[]
+| `index` and `manage` on +{beat_default_index_prefix}-*+ indices
+
+ifdef::has_central_config[]
+.2+|Read configurations from Beats central management
+| `monitor` on cluster
+|`beats_admin` role
+endif::has_central_config[]
+|====
+
+// REVIEWERS: Do users need `index` and `manage` on `shrink-beatname-*`, too?
+// Are there other privileges that might be required as indices move through the
+// lifecycle stages?
+
+[[kibana-user-privileges]]
+==== Privileges needed by {kib} users
+
+{kib} users typically need to view dashboards and visualizations that contain
+{beatname_uc} data. These users might also need to create and edit dashboards
+and visualizations.
+ifdef::has_central_config[]
+If you're using Beats central management, they need to create and manage
+configurations.
+endif::has_central_config[]
+
+The privileges required for {kib} users depend on the tasks they need to
+perform: 
+
+[options="header"]
+|====
+|Task | Required privileges and roles
+
+.2+|View {beatname_uc} dashboards
+|`read` on +{beat_default_index_prefix}-*+ indices
+|`kibana_dashboard_only_user` role
+
+.2+|View and edit {beatname_uc} dashboards
+|`read` on +{beat_default_index_prefix}-*+ indices
+|`kibana_user` role
+
+ifdef::has_central_config[]
+.2+|Create and manage configurations in Beats central management
+|`beats_admin` role
+|`kibana_user` role
+endif::[]
+|====
+
+[[learn-more-security]]
+==== Learn more about users and roles
+
+Want to learn more about creating users and roles? See
+{stack-ov}/elasticsearch-security.html[Securing the {stack}]. Also see:
+
+* {stack-ov}/security-privileges.html[Security privileges] for a description of
+available privileges
+* {stack-ov}/built-in-roles.html[Built-in roles] for a description of roles that
+you can assign to users